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1  Introduction 


Background 

Since  personal  computers  came  into  widespread  use,  vendors  of  construction  schedul¬ 
ing  software  have  tried  to  make  getting  data  into  a  critical  path  method  (CPM)  system 
as  easy  as  possible  through  sophisticated  types  of  data  entry,  including  table  editors, 
customizable  data  entry  screens,  and  Graphical  User  Interfaces  (GUI).  CPM  features 
such  as  resource  analysis,  progress  and  cost  features,  and  default  activity  progress 
data  reduce  manual  data  input  and  analysis.  Output  to  laser  printers  and  plotters  is 
easy  to  produce,  attractive,  and  of  very  high  quality  (East  1£8$). 

MO 

With  all  of  this  automation  power  available,  why  then  has  such  software  not  reduced 
the  need  for  a  full-time  human  scheduler  for  construction  projects?  One  reason  is  that 
project  participants  have  difficulty  receiving  scheduling  data  in  a  useful  form.  Often, 
project  data  is  transferred  between  project  participants  on  paper.  This  format  requires 
each  office  to  retype  the  schedule  into  the  local  scheduling  software  and  then  check  for 
errors.  Retyping  and  checking  schedule  data  could  easily  take  several  days  for  a  small 
project,  and  up  to  a  week  for  large  projects.  Data  might  also  need  to  be  retyped  and 
checked  every  time  a  schedule  is  updated  or  changed. 

Transferring  project  data  electronically  rather  than  manually  would  significantly 
reduce  both  transfer  time  and  labor  costs.  Today  there  are  several  ways  to  support 
electronic  file  transfer.  The  most  common  mechanisms  are  supported  by  individual 
scheduling  software  vendors;  however,  each  vendor  uses  their  own  proprietary  system 
to  handle  and  translate  the  data.  Many  vendors  have  implemented  direct  data 
transfers  among  the  different  proprietary  systems,  but  the  data  transfer  mechanisms 
must  be  constantly  updated  as  each  software  system  is  updated. 

One  government  agency,  the  Veteran's  Administration  (VA),  has  an  electronic  file 
format  that  may  be  used  to  transfer  data  tapes  between  the  contractor  and  VA  offices. 
However,  the  VA  format  requires  the  use  of  centralized,  mainframe-based  scheduling 
that  is  impractical  for  most  organizations.  In  addition,  the  VA  format  does  not  support 
new  scheduling  capabilities  now  commonly  used,  such  as  precedence  diagramming 
techniques. 
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Objectives 

The  objective  of  this  SDEF  project  is  to  develop  and  implement  a  standard  data  format 
and  planning  protocols  across  the  entire  construction  industry.  This  will  reduce  the 
cost  of  construction  projects  through  increased  efficiency  and  effectiveness  of  project 
control  techniques. 


Approach 

Constant  support  over  a  period  of  six  years  from  the  Construction  Division  and 
Construction  Evaluation  Branch  of  the  Military  Programs  Directorate  of  the  U.S. 
Army  Corps  of  Engineers  allowed  the  U.S.  Army  Construction  Engineering  Research 
Laboratories  (USACERL)  to  facilitate  the  development  of  an  industry  standard  for  the 
exchange  of  project  planning  and  control  information. 

A  preliminary  standard  format  was  created,  and  specifications  were  developed  by  com¬ 
bining  the  best  parts  from  Corps  of  Engineers  and  private  industry  specifications.  At 
the  same  time,  it  was  agreed  that  the  standard  should  apply  to  as  many  scheduling 
systems  as  possible  with  as  little  computer  programming  effort  as  possible,  and  that 
the  standard  should  be  flexible  enough  to  be  used  on  a  wide  range  of  construction 
projects. 

Testing  of  the  preliminary  format  at  the  Omaha  and  Alaska  Districts  led  to  revisions. 
The  revised  format  is  the  Standard  Data  Exchange  Format  (SDEF).  Vendors'  products 
were  tested  against  the  SDEF's  requirements  in  July  1994  and  January  1995,  to  see 
if  they  were  SDEF  compatible. 

Finally,  a  validation  program  was  written  to  allow  Construction  Field  Office  personnel 
to  determine  if  a  Contractor's  data  disk  meets  the  format.  This  program  is  named  the 
SDEF  Checker. 


Scope 

The  SDEF  is  required  for  all  contractors  working  on  Corps  of  Engineers  Projects  where 
the  Corps  of  Engineers  Construction  Office  will  be  evaluating  contractors’  construction 
schedules  using  inhouse  software;  these  contractors  must  exchange  scheduling  and 
progress  data  using  the  SDEF. 
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This  report  describes  the  development  of  the  SDEF  and  software  testing  conducted  in 
July  1994  and  in  January  1995.  Appendices  describe  the  SDEF  and  compare  five 
vendors'  products  against  its  requirements. 


Mode  of  Technology  Transfer 

This  project  began  through  the  collaboration  of  over  20  commercial  software  vendors. 
These  vendors  have  incorporated  the  SDEF  into  their  systems  and  will  provide  users 
of  their  systems  with  documentation.  Ultimately,  five  vendors  included  the  format 
developed  directly  into  their  commercial  software  products. 

Guide  Specification  01310  (December  1994),  “Project  Schedule,”  requires  the  use  of  the 
SDEF.  The  Appendix  to  the  U.S.  Army,  Corps  of  Engineers  Engineering  Regulation 
ER  1-1-11  contains  the  SDEF  Technical  Specifications.  The  SDEF  Checker  program, 
which  checks  whether  a  contractor's  data  disk  meets  the  SDEF,  is  available  on  the 
Internet  and  the  CivilNet  (for  location  information,  contact  U.S.  Army  Corps  of 
Engineers,  ATTN:  Bill  East  [CECER-FFA],  P.O.  Box  9005,  Champaign,  IL  61826- 
90005). 

Coordination  with  other  Federal  agencies  is  being  accomplished  through  the  Federal 
Facility  Council  to  promote  the  format  across  all  Federal  agencies  in  charge  of 
construction. 
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2  History  of  the  SDEF  Development 

Proprietary  Specifications  Spark  Bid  Protests 

In  1986,  USACERL  was  contacted  to  assist  the  U.S.  Army  Corps  of  Engineers,  Seattle 
District  with  a  problem  concerning  their  scheduling  specifications.  The  Seattle 
District  was  being  confronted  with  a  wide  range  of  CPM  software  used  by  Corps 
contractors.  At  the  time,  the  District  had  only  two  options:  either  to  specify  a  single 
scheduling  system,  or  to  purchase  and  learn  each  contractor’s  scheduling  system. 
Daunted  by  the  prospect  of  reviewing  contractor  schedules  produced  by  a  potentially 
unlimited  number  of  different  software  packages,  Seattle  District  chose  to  specify  a 
single  software  system.  This  created  a  new  problem:  a  software  vendor  submitted  a 
bid  protest,  citing  the  proprietary  nature  of  the  specification. 

Prompted  by  the  bid  protest,  specifications  from  other  districts  were  reviewed.  In 
addition  to  requirements  for  specific  software,  other,  more  subtle  types  of  proprietary 
specifications  were  found.  One  of  the  most  frequent  was  that  contractors  would  be 
required  to  provide  hardware,  software,  and  training  for  any  scheduling  software  they 
wished  to  use  that  was  not  the  same  as  the  Corps’.  On  smaller  projects,  this 
essentially  required  contractors  to  either  revise  their  own  internal  business  practices 
or  not  submit  a  competitive  bid.  Another  type  of  specification  encountered  required 
the  contractor  to  submit  a  data  disk  containing  the  scheduling  information  in  the 
proprietary  format  of  the  vendor  used  by  the  Construction  Office. 

After  consultation  with  various  software  vendors  and  Corps  personnel,  a  new  option 
emerged.  This  option  would  allow  contractors  to  use  whatever  software  they  wanted 
to,  then  Corps  personnel  would  be  able  to  import  the  contractor’s  schedule  into  the 
Corps  system.  This  new  option  would  eventually  become  the  Standard  Data  Exchange 
Format  (SDEF). 

The  idea  was  that  if  a  common  denominator  could  be  found  between  all  the  commercial 
software  vendors,  then  a  standard  data  format  could  be  specified  that  would  provide 
advantage  to  no  individual  vendor.  A  draft  format  was  circulated  to  the 
manufacturers  of  PMS-80,  Open  Plan,  Primavera,  PROMIS,  PMSII,  PPMS30,000,  and 
ViewPoint,  and  provided  to  the  Seattle  District  on  14  January  1987. 
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Format  Workshop  -  September  1988 

In  the  summer  of  1988,  the  Corps  of  Engineers  National  Quality  Assurance  Team  met 
and  determined  the  need  to  develop  a  generic  format  for  data  exchange  between 
project  management  scheduling  programs.  As  a  result,  the  “Project  Management 
System  Data  Exchange  Format”  project  was  initiated,  and  a  workshop  was  held  in 
September  1988  to  review  a  draft  format.  Workshop  participants  included  software 
vendors,  representatives  of  construction  industry  associations,  construction  manage¬ 
ment  firms,  and  Corps  of  Engineers  personnel.  The  goal  of  the  workshop  was  to  “allow 
project  management  systems  to  easily  share  information  with  other  programs.  The 
focus  of  the  data  exchange  standard  will  be  transferring  scheduling  data  between 
project  management  systems.”  (Conference  notes,  1988) 

The  participating  software  vendors  were:  Advanced  Project  Approach,  Inc.  (PPMS- 
30,000),  AlderGraf  Systems,  Inc.  (AlderGraf  Scheduling  System),  Computerline 
(Plantrac),  North  American  Mica,  Inc.  (PMS-II),  Pinnell  Engineering,  Inc.  (PMS-80), 
Primavera  (Primavera  Project  Planner),  Strategic  Software  Planning  Corp.  (PROMIS), 
and  Welcom  Software  Technology  (Open  Plan).  Representatives  from  the  National 
Construction  Software  Association  (NCSA)  and  the  Construction  Management  Asso¬ 
ciation  of  America  (CMAA)  attended  the  conference.  One  construction  management 
firm,  Brownell,  Bitner,  and  Associates  was  represented,  and  several  attendees  per¬ 
formed  scheduling  and  claims  consulting  in  conjunction  with  software  development. 
Finally,  there  were  representatives  from  several  different  parts  of  the  Corps  of  Engi¬ 
neers,  from  the  Chief  of  Engineers  Office  to  construction  field  offices. 

To  guide  the  development  of  the  format,  the  following  assumptions  were  agreed  upon: 
First,  that  the  standard  should  apply  to  as  many  scheduling  systems  as  possible  with 
as  little  computer  programming  effort  as  possible.  Second,  that  a  complete  set  of 
project  data  would  be  provided  with  every  schedule  update.  Third,  that  the  standard 
should  be  flexible  enough  to  be  used  on  a  wide  range  of  construction  projects. 

It  was  also  agreed  that  to  support  a  wide  range  of  projects,  the  potential  format  would 
need  to  include  two  different  types  of  data  fields.  Required  data  fields  in  the  standard 
represent  minimum  data,  and  provide  an  adequate  level  of  schedule  control  for  most 
smaller  projects.  Optional  fields  support  larger  project  scheduling  requirements. 
Specific  guidelines  were  to  be  developed  regarding  when  specification  writers  should 
include  the  optional  fields. 

Following  the  September  1988  workshop,  a  proposed  data  exchange  format  and 
specifications  governing  its  use  were  developed.  The  specifications  were  developed  by 
combining  the  best  parts  from  a  large  number  of  Corps  of  Engineers  and  private 
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industry  specifications.  Additional  sections  were  written  to  give  contractors  precise 
information  about  how  to  use  the  schedule.  Certain  sections  of  the  specification  also 
described  the  ownership  of  float,  the  contents  of  progress  update  meetings,  time 
management  techniques,  requirements  for  schedule  updates  to  justify  time  extensions, 
and  who  would  be  responsible  to  pay  for  schedule  changes.  The  purpose  of  these 
sections  was  to  clarify  the  use  of  scheduling  to  contractors.  The  opening  section  of  the 
specification,  shown  below,  describes  how  and  why  the  schedule  will  be  used  on  the 
project. 

The  [CPM  network]  is  required  to  assure  adequate  planning  and  coordination  of  the 
contract  work  with  the  work  of  others;  for  providing  a  means  of  measuring  the 
execution  of  the  work;  to  assist  the  Contracting  Officer  in  appraising  the 
reasonableness  of  the  proposed  schedule,  in  appraising  future  funding 
requirements,  to  aid  in  evaluating  the  progress  of  work,  and  assist  in  the 
evaluation  of  time  extensions  (ER  1-1-11,  Appendix  B,  15  March  1990,  p  3,  item  8). 


Format  and  Testing  and  Results  -  Summer  1989 

Two  Districts,  Alaska  and  Omaha,  were  selected  to  become  test  sites  for  the  format 
developed  in  September  1988.  The  results  from  these  Districts  were  discussed  at  a 
second  workshop  held  in  June  1989.  According  to  the  Omaha  District  test  report,  the 
exchange  of  the  data  “went  very  well  with  no  significant  problems.”  The  conclusion  of 
the  Omaha  District  test  was: 

The  Omaha  District  feels  this  data  exchange  format  will  greatly  benefit  our 
construction  management  efforts  by  enabling  and  promoting  the  use  of  computers 
in  schedule  analysis.  The  benefit  will  be  most  tangible  in  the  purchase  of  and 
training  on  one  brand  of  software  rather  than  unique  software  for  each  project.  The 
time  spent  learning  and  becoming  proficient  on  one  brand  of  software  will  be 
greatly  reduced. 

The  Omaha  District  feels  that  this  standard  format  for  scheduling  data  exchange 
should  be  put  into  use  by  as  many  software  vendors  as  possible,  and  as  soon  as 
possible.  (East  et  al.  1989,  p  45) 

While  the  Alaska  District  test  report  supported  the  idea  of  the  data  exchange  format, 
the  author  of  the  test  report  was  not  quite  as  positive  about  the  role  of  the  software 
vendors,  who  apparently  failed  to  update  their  software  correctly: 

This  test  was  unable  to  fully  evaluate  the  two  proprietary  programs,  it  was 
discovered  our  Resident  Office  had  the  incorrect  version  of  [system  name]  and  the 
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software  did  not  function  as  expected.  Time  and  budget  constraints  would  not 
permit  the  procurement  of  the  proper  version  in  time.  This  was  a  problem  not 
foreseen  at  the  onset  and  Omaha  test  site  did  accomplish  the  data  transfer  with  the 
correct  software.  The  data  exchange  format  received  in  the  test  was  manually 
checked  and  would  have  successfully  loaded.  The  alternate  [system  name]  program 
produced  the  proper  output  report,  but  would  not  transfer  back  due  to  incorrect 
software  versions.  Both  of  the  programs  tested  could  have  functioned  if  all  software 
needed  for  the  test  had  been  provided  by  the  vendors.  More  testing  is  needed  to 
solve  inherent  compatibility  problems.  Test  was  successful  enough  for  use  on 
another  project.  (East  et  al.  1989,  p  71) 

In  addition  to  the  tests  at  Omaha  and  Alaska  Districts,  the  format  was  distributed  to 
all  Divisions  and  Districts  in  May  1989  for  comment.  While  Districts  who  had  existing 
specifications  for  particular  software  systems  were  unclear  as  to  the  intent  of  the 
specifications,  several  Districts  responded  very  positively  to  the  idea  of  a  standard  data 
exchange  format.  Several  representative  samples  of  the  results  are  provided  below. 

The  format  is  past  due.  Your  projected  benefits/savings  from  implementation  of  the 
standard  appear  to  be  conservative.  Also,  maybe  scheduling  will  finally  become 
“standard.”  If  this  occurs,  benefits  in  efficiency  and  costs  savings  could  be 
enormous. 

--Chief,  Construction  Division, 
Nashville  District  (Hall,  1989) 

The  development  of  a  data  exchange  standard  is  essential  if  we  are  to  fully  benefit 
from  the  power  of  modern  scheduling  systems. 

-Acting  Chief,  Construction-Operations, 
North  Pacific  Division  (Schmidt,  1989) 

Standardization  of  scheduling  data  exchange  format  will  allow  the  Corps  and 
construction  contractors  to  use  a  program  best  suited  to  their  needs  and  eliminate 
the  necessity  in  learning  new  software.  We  support  this  standard. 

-Chief,  Construction-Operations  Division, 
Ohio  River  Division  (Kiper,  1989) 

Most  of  these  Districts  thought  that  the  idea  of  data  exchange  was  good  but  that  the 
draft  specifications  that  accompanied  the  format  should  be  revised.  One  respondent 
correctly  indicated  that  any  change  to  guide  specifications  should  be  initiated  by 
HQUSACE,  not  USACERL,  but  concluded  that: 
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Notwithstanding  the  above  criticism,  the  draft  specifications  are  good,  and  greatly 
needed.  The  approach  to  data  exchange  is  excellent,  and  will  assure  compatibility 
without  limiting  competition. 


-Acting  Chief,  Construction  Division, 
Kansas  City  District  (Gillian,  1989) 

While  initial  results  appeared  positive,  the  tests  at  Omaha  and  Alaska  hit  snags  due 
to  problems  with  incompatible  scheduling  software,  the  lack  of  resources  required  to 
determine  if  data  submitted  were  in  the  correct  format,  and  the  short  duration  of  the 
test. 

The  results  of  the  format  test,  as  reported  in  August  1989,  were  not  as  positive  as  they 
had  initially  seemed.  An  examination  of  the  details  of  the  Omaha  District's  report 
uncovered  that  some  data  items  had  not  been  provided  by  the  scheduling  system  used 
by  Omaha  District.  This  additional  data  needed  to  be  entered  manually  into  the  file 
for  the  data  exchange  to  occur.  Also,  Omaha  District  did  not  use  many  of  the  optional 
items  included  in  the  data  exchange  format.  The  Alaska  District  also  had  difficulties 
with  the  use  of  the  format,  due  to  unresponsive  vendor  participation. 


Format  Specification  -  March  1990 

Based  on  the  optimistic  interpretation  of  test  results  and  because  of  potential  benefit 
to  the  construction  field  offices,  a  final  draft  of  the  format  was  developed  and  included 
in  Corps  of  Engineers  regulation  ER  1-1-11  in  March  1990  as  Appendix  B.  There  was 
no  testing  program  to  ensure  that  vendors  fully  complied  with  the  format,  with  the 
result  that  the  import  and  export  routines  of  various  systems  differed. 

To  make  files  work,  users  would  first  have  to  perform  detailed  testing  to  determine 
how  to  obtain  the  correct  data  in  the  correct  place  within  the  data  exchange  format, 
because  the  vendors'  system  documentation  did  not  provide  sufficient  information. 
While  some  of  the  requirements  were  quite  simple  (for  example,  using  only  the  first 
30  characters  of  an  activity  description  so  that  activity  names  would  not  be  truncated), 
other  system’s  requirements  forced  users  to  set  up  a  complicated  set  of  dictionaries  for 
activity  codes.  Some  systems  required  that  the  user  create  new  screen  forms  to 
customize  the  existing  user  interface. 

Many  systems  also  had  features  that  were  beyond  the  capabilities  of  the  SDEF  to 
represent.  The  use  of  multiple  resources  and  different  types  of  milestones  are  two 
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examples.  Vendors  did  not  adequately  warn  users  against  using  such  specialized 
features  during  the  creation  of  data  exchange  projects. 

Once  a  file  was  created,  changes  might  still  be  needed  to  allow  it  to  be  exported.  For 
example,  some  systems  produced  files  that  began  with  a  blank  line.  This  blank  line 
would  have  to  be  deleted.  Even  if  the  entire  file  was  correct,  a  simple  additional  line 
at  the  beginning  of  a  file  caused  most  import  routines  to  fail.  Other  systems  required 
that  the  identification  for  the  first  data  disk  be  provided  in  the  file  as  disk  “01”.  In 
this  case,  the  preceding  zero  had  to  be  added  before  importing  any  files. 

Although  CPM  is  commonly  used  to  model  contraction,  there  are  significant  differences 
between  various  software  vendors'  implementation  of  CPM.  Many  systems  allow  the 
use  of  default  calculation  methods,  such  as  not  requiring  Actual  Start  and  Actual 
Finish  dates  on  activities  that  have  been  fiscally  completed.  In  addition,  time-based 
percent  completes  are  often  used  to  drive  the  earned  value  of  an  activity.  In  the  area 
of  cost-  and  time-based  completion,  vendors  provided  insufficient  documentation  about 
the  correct  combination  of  software  features  needed  to  produce  the  data  disk. 

The  March  1990  format  included  required  and  optional  data  items.  Many  of  the 
optional  data  items  could  be  user-defined.  It  was  hoped  that  these  user-defined  items 
would  be  useful  for  larger  projects.  Unfortunately,  user-defined  items  were  also  a  point 
of  confusion. 

In  addition  to  the  problems  of  needing  to  reverse-engineer  the  computer  software, 
tinker  with  the  results  of  the  output,  and  determine  the  meaning  of  optional  items, 
vendors'  own  sales  representatives  hindered  application  of  the  format.  Several  con¬ 
struction  field  offices  representatives  reported  to  the  author  that  vendor  salespeople 
were  actively  recommending  against  the  use  of  the  format  in  lieu  of  purchasing  their 
proprietary  systems.  Although  the  national  offices  of  many  vendors  were  fully  aware 
of  the  March  1990  format,  reports  of  sales  representatives  indicated  that  they  were 
generally  not  aware  that  there  was  a  generic  format  for  the  exchange  of  project 
planning  data. 


Creating  the  SDEF 

As  a  result  of  the  difficulties  with  the  March  1990  format,  a  new  format  was  prepared. 
This  format  revised  three  areas  of  the  March  1990  format.  First,  optional  and  user- 
defined  codes  were  replaced  with  a  specific  set  of  activity  codes.  Second,  new 
information  related  to  the  scheduled  dates  for  activities  and  their  total  float  was 
included  in  the  format.  Finally,  some  changes  were  made  to  activity  costs.  These 
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changes  were  made  to  give  more  specific  direction  to  previously  confusing  data,  and 
to  allow  the  data  in  the  format  to  be  used  by  other  construction  management 
information  systems.  The  draft  of  this  revised  format  that  will  be  published  in  a 
revision  of  ER  1-1-11  is  contained  in  Appendix  A. 

A  new,  official  name  was  selected  for  the  revised  format:  the  Standard  Data  Exchange 
Format  (SDEF).  The  new  name  and  the  format  were  announced  by  the  Chief  of 
Engineers  to  software  vendors  in  August  1993.  Over  200  vendors  were  initially 
contacted.  Thirty  of  these  vendors  requested  information  on  the  format.  Six  vendors, 
covering  approximately  95  percent  of  Corps  of  Engineers  offices,  submitted  software 
for  testing.  These  vendors  (with  their  products  listed  in  parentheses)  were:  Advanced 
Project  Approach,  Inc.  (PPMS  30,000),  AlderGraf  Systems,  Inc.  (AlderGraf),  Integrated 
Software  Systems  (Time  Machine),  Pinnell-Busch,  Inc.  (PMS-80),  Primavera  Systems, 
Inc.  (P3  for  DOS)  and  Welcom  Technologies  Corporation  (Open  Plan). 


Software  Testing— July  1994 

A  session  to  test  software  against  the  SDEF,  conducted  by  Corps  of  Engineers  District 
and  Construction  Office  representatives,  was  held  on  the  campus  of  the  University  of 
Illinois  in  July  1994.  Appendix  B  lists  the  names,  addresses,  and  telephone  numbers 
of  the  testing  personnel. 

The  testers  reviewed  the  submitted  software  using  the  test  questionnaire  shown  in 
Appendix  C.  Sample  projects  were  created  to  test  import  and  export  routines.  The 
result  of  the  evaluation  was  that  vendors  did  not  fully  meet  the  format  s  requirements. 
In  addition  to  not  correctly  producing  SDEF  files,  many  software  systems  did  not 
provide  sufficient  documentation.  Tinkering  with  the  resulting  data  exchange  file  was 
also  necessary  for  some  systems. 

The  July  1994  testers  concluded  that  none  of  the  vendors  who  submitted  software 
performed  adequate  quality  control  testing  to  ensure  that  their  software  fully  met  the 
SDEF  format.  Vendors  were  given  a  list  of  specific  items  to  correct  and  were  asked 
to  resubmit  software  for  a  final  confirmation  test  in  January  1995. 


Software  Testing— January  1995 

Five  of  the  six  vendors  who  submitted  their  products  for  the  July  1994  test 
resubmitted  them  for  January  1995.  Only  Integrated  Software  Systems  (Time 
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Machine)  did  not  implement  the  noted  changes.  USACERL  conducted  tests  on  the 
remaining  five  vendors'  systems. 

The  January  1995  testing  consisted  of  a  detailed  review  of  each  software  system  to 
determine  the  exact  correspondence  between  the  SDEF  data  fields  and  the  fields  in 
that  scheduling  software  system.  Several  simple  projects  were  developed  or  modified 
from  existing  examples  to  provide  a  set  of  test  cases.  These  test  projects  were 
manually  entered  into  the  software  systems,  and  the  SDEF  export  file  was  run 
through  the  SDEF  Checker  program.  While  creating  the  test  projects,  testers  tried  out 
the  various  permutations  of  values  available  at  each  significant  data  field  and 
evaluated  the  impact  on  the  resulting  SDEF  file  or  imported  data. 

Each  system  tested  was  installed  according  to  the  user’s  manual  and  supplemental 
instructions  on  the  test  platform  described  below.  The  testing  resulted  in  incremental 
refinement  of  vendors'  SDEF  import/export  routines  into  February  1995.  Many 
vendors  submitted  four  or  five  additional  program  updates  to  USACERL  to  fix  some 
aspect  of  their  SDEF  routines.  By  mid-February  of  1995,  vendors'  SDEF  import/export 
routines  had  stabilized  enough  to  announce  the  list  of  vendors  recommended  for  use 
with  the  SDEF  specification.  The  detailed  evaluation  of  each  system  is  provided  in 
Appendix  D  through  Appendix  H. 

Test  Platform 

The  test  platform  was  an  IBM-compatible  personal  computer  with  the  following 
configuration: 

Processor: 

Operating  System: 

Largest  Executable  Program  Size 
Free  Extended  Memory  Free: 

Memory  Driver: 

Network: 

Windows: 

Mouse  Driver: 


Intel  80486/66  Mhz 

MS-DOS  version  6.20 

610  KB 

31,680  KB 

MS-DOS  himem.sys 

not  installed  (to  maximize  available 

memory) 

not  installed  (to  maximize  available 
memory) 

C:\WINDOWS\MOUSE.SYS  /Y 


The  contents  of  the  AUTOEXEC.BAT  file  are  shown  below.  (PATH  and  SET  com¬ 
mand  lines  for  each  system  were  customized  as  required  by  that  software  system.) 
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PROMPT  $p$g 
PATH=C:\DOS;C:\BIN 

The  contents  of  the  CONFIG.SYS  file  are  shown  below. 

DEVICE=C:\DOS\HIMEM.SYS 

DEVICE=C:\DOS\ANSI.SYS 

DEVICE=C:\WINDOWS\MOUSE.SYS  /Y 

BUFFERS=16 

FILES=128 

DOS=HIGH,UMB 

LASTDRIVE=E 

FCBS=16,0 

STACKS=9,256 

Issues  Raised 

During  the  testing,  several  important  issues  were  raised  regarding  requirements  of  the 
SDEF  files.  These  issues  are  described  below  and  may  in  the  future  help  further 
clarify  SDEF  requirements. 

Volume  Record  Clarification.  The  first  line  of  an  SDEF-compatible  file  must  contain 
the  VOLM  record.  Systems  must  make  sure  that  the  export  routines  do  not  place  a 
blank  line  as  the  first  line  in  the  SDEF  file.  If  the  VOLM  record  is  not  the  first  line  of 
the  file,  the  file  will  be  rejected  by  other  systems  as  non-SDEF  compatible. 

Project  Record  Clarification.  The  second  record  in  an  SDEF  file,  PROJ,  contains 
global  information  about  a  project.  This  global  information,  while  useful,  may  also 
impact  schedule  calculations  in  ways  that  are  inconsistent  between  scheduling 
software.  Vendors  have  been  asked  to  include  a  discussion  of  the  following  paragraph 
in  revised  SDEF  documentation: 

The  use  of  “project  start”  and  “project  end”  dates  differs  between  systems.  Because 
these  dates  may  result  in  different  schedule  calculations  when  used  in  various 
software  systems,  it  is  recommended  that  users  do  not  provide  information  on 
global  project  start  and  end  dates.  A  project  start  date,  for  example,  may  require 
that  the  first  activity  in  the  schedule  occur  on  a  specific  date  or  only  after  a  certain 
date.  The  recommended  way  to  ensure  that  projects  start  at  the  same  time  regard¬ 
less  of  the  scheduling  system  used  is  by  placing  a  early  start  constraint  on  the  first 
activity  in  the  schedule.  Similarly,  rather  than  using  a  global  project  end  date, 
using  a  finish  no  later  than  constraint  on  the  last  activity  of  the  schedule  will 
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produce  a  project  plan  that  can  be  scheduled  consistently  between  various  software 
systems. 

Calendar  Record  Clarification.  The  Calendar  Record  and  ACTV  record  allow  calendar 
designations  to  be  alphanumeric.  This  feature  is  not  supported  by  several  vendors  who 
require  numbers  for  calendar  codes.  Vendors  have  been  notified,  and  agreed,  that 
calendar  codes  may  only  take  values  from  1  to  9. 

Activity  Identifier  Clarification.  The  SDEF  requires  that  the  activity  identification  in 
the  ACTIVITY  ID  field  be  an  integer.  Because  many  users  and  systems  allow  letters 
and  numbers  in  the  ACTIVITY  ID  field,  users  may  want  to  determine  the 
requirements  of  the  systems  being  used  by  every  other  project  team  member.  If  the 
project  team's  systems  all  support  alphanumeric  activity  identifications,  then  alpha¬ 
numeric  activity  identification  should  be  allowed.  If,  however,  not  all  systems  support 
the  alphanumeric  activity  identification,  then  only  integers  should  be  allowed. 

Activity  Code  Clarification.  When  the  SDEF  Checker  program  reviewed  the 
ACTIVITY  RECORD  in  the  test  projects,  many  activity  codes  were  found  to  be  blank. 
The  SDEF  requires  that  activity  codes  be  present  for  all  activities;  however,  there  are 
many  situations  where  project  planners  may  not  include  activity  codes.  Because 
activity  codes  provide  the  basis  for  analyzing  project  plans,  and  are  essential  for 
progress  reporting,  the  following  alternatives  are  suggested  for  these  situations,  to 
ensure  that  all  activities  have  a  complete  complement  of  codes. 

The  first  case  of  activities  that  may  not  have  codes  are  non-work  activities.  Non-work 
activities  frequently  do  have  a  complete  set  of  activity  codes  because  these  codes  may 
not  appear  to  be  appropriate  for  the  non-work  activity.  For  example,  an  activity 
“Notice  to  Proceed”  does  not  immediately  appear  to  have  a  “responsibility”  or  trade 
associated  with  it.  The  activity  does,  however,  have  a  responsible  party,  namely  the 
owner  who  issues  the  order  to  start  the  project.  To  code  such  an  activity,  a  code  value 
should  be  created  for  each  member  of  the  construction  team.  Another  example  of  a 
non-work  activity  that  might  be  without  a  code  is  that  of  “phase  of  work”  for  an 
activity  called  “Deliver  Steel.”  In  this  case  it  is  recommended  that  a  phase  of  work 
coded  as  “P”  for  procurement  or  “DE”  for  delivery  be  developed.  In  each  case  of  non¬ 
work  activities,  meaningful  activity  codes  may  be  created  by  taking  a  global  project 
view. 

Another  approach  to  the  missing  activity  codes  is  to  run  the  SDEF  Checker  program 
to  identify  activities  without  codes.  After  providing  activity  codes  where  appropriate, 
using  the  strategies  described  above,  rerun  the  SDEF  Checker  and  turn  off  checks  for 
the  remaining  activity  codes  that  are  missing.  Note  that  while  turning  off  checks 
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allows  schedules  to  be  approved  without  a  full  complement  of  codes,  it  may  not  allow 
project  managers  to  fully  evaluate  the  schedule. 

The  other  case  of  missing  activity  codes  occurs  with  dummy  activities  in  arrow 
diagrams.  Dummy  activities  will  produce  SDEF  Checker  activity  code  errors  just  like 
any  other  activity  if  the  activity  codes  are  missing.  It  is  recommended  that  users  run 
the  SDEF  Checker  once  with  all  activity  code  options  turned  on,  and  then  make  sure 
that  only  dummy  activities  are  missing  activity  codes.  Once  satisfied  that  only 
dummy  activities  are  missing  activity  codes,  the  option  to  check  the  activity  codes  may 
be  turned  off.  Rechecking  the  file  will  then  ignore  the  missing  codes  on  dummy 
activities. 

Unit  Cost  Clarification.  For  systems  that  support  unit  costs,  the  Unit  Cost  Record 
caused  the  most  problems  in  conforming  to  recommended  SDEF  usage.  The  difficulty 
results  from  the  differences  between  systems  when  it  comes  to  the  area  of  resources. 
Those  interested  in  unit  costs  should  be  aware  that  the  systems  require  (1)  manual 
calculation  of  ACTIVITY  COST  and  COST  TO  DATE  in  the  Progress  Record  and  (2) 
detailed  understanding  of  the  resource  systems  for  the  software  importing  and 
exporting  the  unit  cost  data. 

As  noted  in  the  SDEF,  only  one  unit  cost  item  may  be  associated  with  a  single  activity. 
If  there  are  several  activities  that  have  the  same  type  of  unit  cost  item,  then  these  will 
be  identified  as  activities  that  have  the  same  pair  of  “cost  per  unit”  and  “unit  of 
measure”  fields. 

Activity  Costs  Clarification.  Three  cost  items  in  the  Progress  Record  caused  some 
confusion.  As  happens  with  most  nomenclature  for  costs,  different  people  have 
different  definitions  for  the  same  items.  Vendors  implementing  the  SDEF  in  the 
future  should  review  the  definitions  of  the  data  items  to  ensure  that  the  most 
appropriate  software  field  is  mapped  to  the  SDEF  data  field.  For  example  the  COST 
TO  DATE  field  description  corresponds  to  the  earned  value  for  the  tasks.  For  those 
systems  that  have  implemented  the  Cost/Schedule  Control  System  (C/SCS)  control 
process,  the  SDEF  costs  sire  the  budgeted  and  actual  earned  value.,  and  the  STORED 
MATERIAL  cost  should  be  included  in  the  COST  TO  DATE  field. 

If  there  is  a  unit  cost  record  associated  with  the  activity,  then  the  values  for  the 
ACTIVITY  COST  and  COST  TO  DATE  should  be  generated  by  the  Unit  Costs  Record. 
Manual  calculation  is  frequently  required  to  ensure  that  costs  fields  for  UNIT  COST 
or  for  STORED  MATERIAL  are  correctly  reflected  in  the  Progress  Record. 
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Activity  Actual  Date  Clarification.  CPM  scheduling  requires  that  activities  that  have 
started  have  an  actual  start  date  and  that  completed  activities  have  an  actual  finish 
date.  Software  systems  have  frequently  allowed  users  to  deviate  from  this  require¬ 
ment  by  providing  default  values  for  start  and  finish  dates  if  dates  have  not  been 
provided.  The  SDEF  requires  an  ACTUAL  START  DATE  if  either  the  REMAINING 
DURATION  is  less  than  the  ORIGINAL  DURATION,  or  if  the  ACTUAL  COST  costs 
or  STORED  MATERIAL  costs  are  greater  than  zero.  An  ACTUAL  FINISH  DATE  is 
required  when  the  REMAINING  DURATION  is  equal  to  zero.  The  ACTUAL  COST 
field  need  not  be  equal  to  the  budgeted  cost  for  activities  identified  as  completed, 
because  there  may  be  punch-list  or  other  uncompleted  items  for  which  funds  are  being 
withheld. 

While  testing  has  identified  some  situations  where  the  use  of  default  dates  has 
resulted  in  creation  of  incorrect  SDEF  files,  not  all  features  of  every  system  have  been 
tested  to  100  percent  confidence.  Vendors  have  been  asked  to  include  in  their 
documentation  a  suggestion  that  users  do  not  utilize  these  default  dates  unless  the 
results  have  been  fully  investigated. 
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3  Recommended  Vendors 

All  of  the  five  scheduling  systems  resubmitted  to  USACERL  for  testing  in  January 
1995  were  able  to  export  and  import  files  that  complied  with  the  SDEF  format.  Table 
1  lists  the  vendor  and  point  of  contact  for  each  of  these  systems,  and  Appendices  D 
through  H  describe  their  SDEF  capabilities.  Users  of  these  systems  who  wish  to  use 
the  SDEF  routines  should  review  the  appropriate  Appendix,  and  should  contact  the 
vendor  for  supplemental  vendor  documentation  to  ensure  that  the  version  of  the 
software  currently  in  circulation  contains  the  most  recent  SDEF  routines. 

Recommendations  for  changes  to  these  products  for  enhanced  compatibility  with  the 
SDEF  are  presented  in  each  product's  respective  Appendix. 

Table  1 .  Recommended  SDEF  vendors. _ _ 

Product _ Company _  Point  of  Contact  Telephone  Number 

AlderGraf  AlderGraf  Systems,  Inc.  LeonAlderfer  (713)467-8500 

v.  5.2 

Open  Plan  Welcom  Software  Technology  Chris  Jenson  (713)558-0514 

v.  5.1  (WST  Corporation)  Randy  Armstrong 

PMS-80  Pinnell-Busch  Engineers,  Inc.  Perry  Smith  (503)  293-6280 

v.  6.40 

PPMS  30,000  Advanced  Project  Approach,  Inc.  Justin  Smith  (214)929-1877 

v.  4.02 

Primavera  Primavera  Systems,  Inc.  Hank  Norris  (215)667-8600 

v.  5.0  Marko  Vranich 
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4  Conclusions  and  Recommendations 


To  provide  compatibility  between  differing  proprietary  construction  scheduling 
systems,  USACERL  has  developed  a  standardized  format,  the  SDEF,  to  provide  a 
common  denominator  for  data  exchange  between  systems.  This  format  has  been 
appended  to  ER  1-1-11  and  is  required  of  all  contractors  for  Corps  of  Engineers 
projects  requiring  electronic  schedule  information.  (An  earlier  format  appears  as 
Appendix  B  in  ER  1-1-11,  but  this  is  not  the  SDEF.)  The  Corps  of  Engineers  Guide 
Specification  (CEGS)  governing  project  scheduling,  CEGS-01310  (December  1994), 
contains  the  necessary  contract  language  to  effectively  use  the  SDEF.  Appendix  A 
shows  a  draft  of  the  SDEF  specification. 

Five  vendors  have  demonstrated  compatibility  with  the  SDEF.  Appendices  D  through 
H  guide  users  of  these  vendors’  products  in  creating,  importing,  and  exporting  projects 
in  the  SDEF.  Recommendations  for  changes  to  these  products  for  enhanced  com¬ 
patibility  with  the  SDEF  are  presented  in  each  product's  respective  Appendix. 
Vendors  will  be  making,  or  already  have  made,  many  of  these  recommended  changes. 
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Appendix  A:  Draft  SDEF  Specification 


STANDARD  DATA  EXCHANGE  FORMAT  SPECIFICATION  1  SEP  1995 
PART  1  -  GENERAL 

1.  Application  of  This  Provision:  The  Standard  Data  Exchange  Format  (SDEF) 
provides  a  non-proprietary  protocol  to  exchange  project  planning  and  progress  data 
between  scheduling  systems. 

2.  File  Type  and  Format:  The  data  file  shall  consist  of  a  132  character,  fixed 
format,  “ASCII”  file.  Text  shall  be  left-justified  and  numbers  shall  be  right-justified 
in  each  field.  Data  records  must  conform,  exactly,  to  the  sequence,  column  position, 
maximum  length,  mandatory  values,  and  field  definitions  described  below  to  comply 
with  the  SDEF.  Unless  specifically  stated,  all  numbers  shall  be  whole  numbers. 
Fields  containing  numbers  shall  not  be  zero  filled.  All  data  columns  shall  be  separated 
by  a  single  blank  column.  The  file  shall  not  contain  blank  lines. 

3.  Usage  Notes:  Where  appropriate,  notes  regarding  proper  usage  of  systems  to 
support  the  SDEF  have  been  included  in  brackets  ( [  ] ).  These  notes  are  included  to 
assist  users  in  creating  SDEF-compatible  files,  given  the  variety  of  software  systems 
that  support  the  SDEF. 

4.  SDEF  Checker  Program:  A  program  that  checks  whether  a  file  meets  the  SDEF 
is  available  free  of  charge.  A  copy  of  this  program  may  be  obtained  by  written  request 
to:  U.S.  Army  Corps  of  Engineers,  ATTN:  Mr.  Bill  East  (CECER-FFA),  P.O.  Box  9005, 
Champaign,  IL  61826-90005.  A  description  of  the  SDEF  Checker  will  be  made 
available  on  the  Internet  and  CivilNet. 


PART  2  -  SDEF  SPECIFICATION 

5.  SDEF  Organization:  The  SDEF  shall  consist  of  the  following  records  provided  in 
the  exact  sequence  shown  below: 
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Paragraph 

Reference 

Record 

Descriotion 

Remarks 

5. a 

Volume  Record 

Mandatory  First  Line  of  File 

5.b 

Project  Record 

Mandatory  Second  Line  of  File 

5.c 

Calendar  Record(s) 

Mandatory  One  Record  Minimum 

5.d 

Holiday  Record(s) 

Mandatory  if  Holidays  Used 

5.e 

Activity  Record(s) 

Mandatory  Records 

5.f 

Precedence  Record(s) 

Mandatory  for  Precedence 

5-g 

Unit  Cost  Record(s) 

Mandatory  for  Unit  Costs 

5.h 

Progress  Record(s) 

Mandatory  Records 

5.1 

File  End  Record 

Mandatory  Last  Line  of  Disk/File 

5.a.  Volume  Record:  The  Volume  Record  shall  be  used  to  control  the  transfer 
of  data  that  may  not  fit  on  a  single  disk.  The  first  line  in  every  file  used  to  store  SDEF 
data  shall  be  the  Volume  Record.  The  Volume  Record  shall  sequentially  identify  the 
number  of  the  data  transfer  disk(s).  The  Volume  Record  shall  have  the  following 
format: 


Descriotion 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

VOLM 

Fixed 

Filled 

DISK  NUMBER 

6-7 

2 

V 

Number 

Right  Justified 

5.a.(l)  The  RECORD  IDENTIFIER  is  the  first  four  characters  of  this  record. 
The  required  value  for  this  field  shall  be  <£VOLM”.  The  VOLM  record  must  appear  on 
the  first  line  of  the  SDEF  data  file. 

5.a.(2)  The  DISK  NUMBER  field  shall  identify  the  number  of  the  data  disk 
used  to  store  the  data  exchange  Fformation.  If  all  data  may  be  contained  on  a  single 
disk,  this  field  shall  contain  the  value  of  “1”.  If  more  disks  are  required,  then  the 
second  disk  shall  contain  the  value  “2”,  the  third  disk  shall  be  designated  with  a  “3”, 
and  so  on.  Identification  of  the  last  data  disk  is  accomplished  in  the  Project  End 
Record. 
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5.b.  Project  Record:  The  Project  Identifier  Record  shall  contain  general 
project  information.  Because  more  than  one  SDEF  file  may  be  required  for  data 
transfer  between  large  projects,  the  PROJ  record  shall  be  the  second  line  of  the  first 
SDEF  file  transferred.  The  PROJ  record  shall  contain  information  in  the  following 
format: 


Description 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

PROJ 

Fixed 

Filled 

DATA  DATE 

6-12 

7 

v/ 

ddmmmyy 

Filled 

PROJECT  IDENTIFIER 

14-17 

4 

y 

Alpha. 

Left  Justified 

PROJECT  NAME 

19-66 

48 

v/ 

Alpha. 

Left  Justified 

CONTRACTOR  NAME 

68  - 103 

36 

y 

Alpha. 

Left  Justified 

ARROW  OR 

PRECEDENCE 

105  - 105 

1 

A,  P 

Fixed 

Filled 

CONTRACT  NUMBER 

107  - 112 

6 

y 

Alpha. 

Left  Justified 

PROJECT  START 

114-120 

7 

•J 

ddmmmyy 

Filled 

PROJECT  END 

122  - 128 

7 

y 

ddmmmyy 

Filled 

5.b.(l)  The  RECORD  IDENTIFIER  is  the  first  four  characters  of  this  record. 
The  required  value  for  this  field  shall  be  “PROJ”.  This  record  shall  contain  the  general 
project  information  and  indicates  which  scheduling  method  shall  be  used. 

5.b.(2)  The  DATA  DATE  is  the  date  of  the  schedule  calculation.  The 
abbreviation  “ddmmmyy”  refers  to  a  date  format  that  shall  translate  a  date  into  two 
numbers  for  the  day,  three  letters  for  the  month,  and  two  numbers  for  the  year.  For 
example,  March  1,  1999  shall  be  translated  into  01Mar99.  This  same  convention  for 
date  formats  shall  be  used  throughout  the  entire  data  format.  To  ensure  that  dates 
are  translated  consistently,  the  following  abbreviations  shall  be  used  for  the  three 
character  month  code: 


Abbreviation 

Month 

JAN 

January 

FEB 

February 

MAR 

March 

APR 

April 

MAY 

May 

JUN 

June 

JUL 

July 

30 
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AUG 

August 

SEP 

September 

OCT 

October 

NOV 

November 

DEC 

December 

5.b.(3)  The  PROJECT  IDENTIFIER  is  a  maximum  four  character  abbreviation 
for  the  schedule.  These  four  characters  shall  be  used  to  uniquely  identify  the  project 
and  specific  update  as  agreed  upon  by  Contractor  and  Contracting  Officer.  When 
utilizing  scheduling  software  these  four  characters  shall  be  used  to  select  the  project. 
Software  manufacturers  shall  provide  information  to  users  to  ensure  that  data 
importing  programs  do  not  automatically  overwrite  other  schedules  with  the  same 
PROJECT  IDENTIFIER. 

5.b.(4)  The  PROJECT  NAME  field  shall  contain  the  name  and  location  of  the 
project  edited  to  fit  the  space  provided.  The  data  appearing  here  shall  appear  on 
scheduling  software  reports.  The  abbreviation  “Alpha.”  refers  to  an  “Alphanumeric” 
field  value  and  shall  be  used  throughout  the  remainder  of  this  specification. 

5.b.(5)  The  CONTRACTOR  NAME  field  shall  contain  the  Construction 
Contractor's  name,  edited  to  fit  the  space  provided. 

5.b.(6)  The  ARROW  OR  PRECEDENCE  field  shall  indicate  which  method  shall 
be  used  for  calculation  of  the  schedule.  The  value  “A”  shall  signify  the  Arrow 
Diagramming  Method.  The  value  “P”  shall  signify  the  Precedence  Diagramming 
Method.  The  ACTIVITY  ID  field  of  the  Activity  Record  shall  be  interpreted  differently 
depending  on  the  value  of  this  field.  The  Precedence  Record  shall  be  required  if  the 
value  of  this  field  is  “P”.  [Usage  note:  software  systems  may  not  support  both  arrow 
and  precedence  diagramming.  It  is  recommended  that  the  selection  of  the  type  of 
network  be  based  on  the  capabilities  of  the  software  used  by  project  partners.] 

5.b.(7)  The  CONTRACT  NUMBER  field  shall  contain  the  contract  number  for 
the  project.  For  example,  the  construction  contract  number  DACA85-89-C-0001  shall 
be  entered  into  this  field  as  “890001”. 

5.b.(8)  The  PROJECT  START  field  shall  contain  the  date  that  the  Contractor 
acknowledges  the  Notice  to  Proceed  (NTP).  [Usage  note:  Software  systems  may  use 
a  project  start  date  to  constrain  the  first  activity  of  a  network.  To  ensure  consistent 
scheduling  calculations  across  products,  it  is  recommended  that  the  first  activity  in  the 
schedule  contain  an  EARLY  START  constraint  and  a  software  system’s  PROJECT 
START  date  only  be  used  to  report  on  the  project's  start  date.] 
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5.b.(9)  The  PROJECT  END  field  shall  contain  the  date  that  the  Contractor 
plans  to  complete  the  work  as  approved  by  the  Contracting  Officer.  [Usage  note: 
software  systems  may  use  a  project  end  date  to  constrain  the  last  activity  of  a  network. 
To  ensure  consistent  scheduling  calculations  across  products,  it  is  recommended  that 
the  last  activity  in  the  schedule  contain  an  EARLY  START  constraint  and  a  software 
system's  PROJECT  END  date  only  be  used  to  report  on  the  project's  end  date.] 

5.c.  Calendar  Record:  The  Calendar  Record(s)  shall  follow  the  Project 
Identifier  Record  in  the  first  disk  of  data  transferred.  A  minimum  of  one  Calendar 
Record  shall  be  required  for  all  data  exchange  activity  files.  The  format  for  the 
Calendar  Record  shall  be  as  follows: 


Description 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

CLDR 

Fixed 

Filled 

CALENDAR  CODE 

6-6 

1 

V 

Alpha. 

Filled 

WORKDAYS 

8-14 

7 

SMTWTFS 

Fixed 

Filled 

CALENDAR  DESCRIPTION 

16  -  45 

30 

V 

Alpha. 

Left  Justified 

5.c.(l)  The  RECORD  IDENTIFIER  shall  always  begin  with  "CLDR"  to  identify 
it  as  a  Calendar  Record.  Each  Calendar  Record  used  shall  have  this  identification  in 
the  first  four  columns.  [Usage  note:  Systems  contain  a  variety  of  calendar  options. 
It  is  recommended  that  the  least  common  denominator  of  calendar  features  between 
the  systems  be  used  as  the  basis  for  creating  the  SDEF  file  for  a  given  project.] 

5.c.(2)  The  CALENDAR  CODE  shall  be  used  in  the  activity  records  to  signify 
that  this  calendar  is  associated  with  the  activity.  [Usage  note:  Some  systems  do  not 
allow  for  alphanumeric  CALENDAR  CODES,  but  only  allow  positive  integers  from  1 
to  9.  It  is  recommended  that  only  positive  integers  be  used  for  the  CALENDAR  CODE 
field  to  support  the  widest  variety  of  scheduling  systems.] 

5.c.(3)  The  WORKDAYS  field  shall  contain  the  work-week  pattern  selected 
with  “Y”,  for  Yes,  and  “N”,  for  No.  The  first  character  shall  be  Sunday  and  the  last 
character  Saturday.  An  example  of  a  typical  five  (5)  day  work-week  would  be 
NYYYYYN.  A  seven  (7)  day  work-week  would  be  YYYYYYY. 

5.c.(4)  The  CALENDAR  DESCRIPTION  shall  be  used  to  briefly  describe  the 
calendar  used. 
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5.d.  Holiday  Record:  The  Holiday  Record(s)  shall  follow  the  Calendar 
Record(s)  in  the  first  disk  of  data  transferred.  There  may  be  calendars  without  any 
holidays  designated  or  several  Holiday  Records  for  each  Calendar  Record(s).  The 
format  for  the  Holiday  Record  shall  be  as  follows: 


Column 

Max. 

Req. 

Description 

Position 

Len. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

HOLI 

Fixed 

Filled 

CALENDAR  CODE 

6-6 

1 

y/ 

Alpha. 

Filled 

HOLIDAY  DATE 

8-14 

7 

v/ 

ddmmmyy 

Filled 

HOLIDAY  DATE 

16-22 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

24-30 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

32-38 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

40-46 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

48-54 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

56-62 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

64-70 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

72-78 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

80-86 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

88-94 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

96  - 102 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

104  - 110 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

112  - 118 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

120  - 126 

7 

- 

ddmmmyy 

May  be  Filled 

5.d.(l)  The  RECORD  IDENTIFIER  shall  always  begin  with  "HOLT.  Each 
Holiday  Record  used  shall  have  this  identification  in  the  first  four  columns. 

5.d.(2)  The  CALENDAR  CODE  indicates  which  work-week  calendar  the 
holidays  shall  be  applied  to.  More  than  one  HOLI  record  may  be  used  for  a  given 
CALENDAR  CODE. 

5.d.(3)  The  HOLIDAY  DATE  shall  contain  the  date  of  each  individual 
non-work  day. 

5.e.  Activity  Records:  Activity  Records  shall  follow  any  Holiday  Record(s). 
If  there  are  no  Holiday  Record(s),  then  the  Activity  Records  shall  follow  the  Calendar 
Record(s).  There  shall  be  one  Activity  Record  for  every  activity  in  the  network.  Each 
activity  shall  have  one  record  in  the  following  format: 
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Description 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

ACTV 

Fixed 

Filled 

ACTIVITY  ID 

6-15 

10 

v/ 

Integer 

See  Comment  Below 

ACTIVITY  DESCR. 

17-46 

30 

v/ 

Alpha. 

Left  Justified 

ACTIVITY  DURATION 

48-50 

3 

>/ 

Integer 

Right  Justified 

CONSTRAINT  DATE 

52-58 

7 

- 

ddmmmyy  May  be  Filled 

CONSTRAINT  TYPE 

60-61 

2 

- 

ES  or  LF 

May  be  Filled 

CALENDAR  CODE 

63-63 

1 

v/ 

Alpha. 

Filled 

HAMMOCK  CODE 

65-65 

1 

Y,  blank 

Fixed 

May  be  Filled 

WORKERS  PER  DAY 

67-69 

3 

- 

Integer 

Right  Justified 

RESPONSIBILITY  CODE 

71-74 

4 

- 

Alpha. 

Left  Justified 

WORK  AREA  CODE 

76-79 

4 

- 

Alpha. 

Left  Justified 

MOD  OR  CLAIM  NO 

81-86 

6 

- 

Alpha. 

Left  Justified 

BID  ITEM 

88-93 

6 

- 

Alpha. 

Left  Justified 

PHASE  OF  WORK 

95-96 

2 

- 

Alpha. 

Left  Justified 

CATEGORY  OF  WORK 

98-98 

1 

- 

Alpha. 

May  be  Filled 

FEATURE  OF  WORK 

100  - 128 

30 

- 

Alpha. 

Left  Justified 

5.e.(l)  The  RECORD  IDENTIFIER  for  each  activity  description  record  must 
begin  with  the  four  character  “ACTV”  code.  This  field  shall  be  used  for  both  the  Arrow 
Diagram  Method  (ADM)  and  Precedence  Diagram  Method  (PDM). 

5.e.(2)  The  ACTIVITY  ID  consists  of  coding  that  shall  differ,  depending  on 
whether  the  ADM  or  PDM  method  was  selected  in  the  Project  Record.  If  the  ADM 
method  was  selected,  then  the  field  shall  be  interpreted  as  two  right-justified  fields  of 
five  (5)  integers  each.  If  the  PDM  method  was  selected,  the  field  shall  be  interpreted 
as  one  (1)  right-justified  field  of  ten  (10)  integers  each.  The  maximum  activity  number 
allowed  under  this  arrangement  is  99999  for  ADM  and  9999999999  for  the  PDM 
method.  [Usage  note:  Many  systems  allow  alphanumeric  ACTIVITY  IDs.  While  the 
SDEF  does  not,  strictly,  allow  the  use  of  alphanumeric  values,  users  may  agree  to  use 
the  ACTIVITY  ID  field  to  exchange  alphanumeric  data.  It  is  recommended  that  the 
ACTIVITY  ID  be  restricted  to  integers  when  one  or  more  of  the  systems  being  used  for 
scheduling  allows  only  integer  ACTIVITY  ID  values.] 

5.e.(3)  The  ACTIVITY  DESCRIPTION  shall  be  a  maximum  of  30  characters. 
Descriptions  must  be  limited  to  the  space  provided. 

5.e.(4)  The  ACTIVITY  DURATION  contains  the  estimated  original  duration 
for  the  activity  on  the  schedule.  The  duration  shall  be  based  upon  the  work-week 
designated  by  the  activity's  related  calendar. 
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5.e.(5)  The  CONSTRAINT  DATE  field  shall  be  vised  to  identify  a  date  that  the 
scheduling  system  may  use  to  modify  float  calculations.  If  there  is  a  date  in  this  field, 
then  there  must  be  a  valid  entry  in  the  CONSTRAINT  TYPE  field. 

5.e.(6)  The  CONSTRAINT  TYPE  field  shall  be  used  to  identify  the  way  that 
the  scheduling  system  shall  use  the  CONSTRAINT  DATE  to  modify  schedule  float 
calculations.  If  there  is  a  value  in  this  field,  then  there  must  be  a  valid  entry  in  the 
CONSTRAINT  DATE  field.  The  valid  values  for  the  CONSTRAINT  TYPE  are  as 
follows: 


Code  Definition 

ES  The  CONSTRAINT  DATE  shall  replace  an  activity's  early 

start  date,  if  the  early  start  date  is  prior  to  the 
CONSTRAINT  DATE. 

LF  The  CONSTRAINT  DATE  shall  replace  an  activity's  late 

finish  date,  if  the  late  finish  date  is  after  the 
CONSTRAINT  DATE. 

[Usage  note:  Systems  provide  a  wide  variety  of  constraint  types  that  may  not 
be  supported  by  other  systems.  It  is  recommended  that  constraint  types  be  restricted 
to  the  values  above  regardless  of  the  capabilities  of  the  various  systems  being  used  for 
scheduling.] 

5.e.(7)  The  CALENDAR  CODE  relates  this  activity  to  an  appropriate  work¬ 
week  calendar.  The  ACTIVITY  DURATION  must  be  based  on  the  valid  work-week 
referenced  by  this  CALENDAR  CODE  field. 

5.e.(8)  The  HAMMOCK  CODE  indicates  that  a  particular  activity  does  not 
have  its  own  independent  duration,  but  takes  its  start  dates  from  the  start  date  of  the 
preceding  activity  (or  node)  and  takes  its  finish  dates  from  the  finish  dates  of  its 
succeeding  activity  (or  node).  If  the  value  of  the  HAMMOCK  CODE  field  is  “Y”,  then 
the  activity  is  a  hammock  activity. 

5.e.(9)  The  WORKERS  PER  DAY  shall  contain  the  average  number  of  workers 
expected  to  work  on  the  activity  each  day  the  activity  is  in  progress.  If  this  code  is 
required  by  project  scheduling  specifications,  values  for  this  data  will  be  right  justified. 
Activities  without  workers  per  day  shall  have  a  value  of  “0”. 

[Usage  note:  The  codes  described  in  paragraphs  5.e.(10)  through  5.e.(16)  are 
commonly  referred  to  as  activity  codes.] 
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5.e.(10)  The  RESPONSIBILITY  CODE  shall  identify  the  subcontractors  or 
major  trade  involved  with  completing  the  work  for  the  activity.  If  this  code  is  required 
by  project  scheduling  specifications,  value  for  this  data  will  be  left  justified. 

5.e.(ll)  The  WORK  AREA  CODE  shall  identify  the  location  of  the  activity 
within  the  project.  If  this  code  is  required  by  project  scheduling  specifications,  value 
for  this  data  will  be  left  justified. 

5.e.(12)  The  MOD  OR  CLAIM  NUMBER  shall  uniquely  identify  activities  that 
are  added  or  changed  on  a  construction  contract  modification,  or  activities  that  justify 
any  claimed  time  extensions.  If  this  code  is  required  by  project  scheduling 
specifications,  value  for  this  data  will  be  left  justified. 

5.e.(13)  The  BID  ITEM  shall  identify  the  bid  item  number  associated  with  each 
activity.  If  this  code  is  required  by  project  scheduling  specifications,  value  for  this  data 
will  be  left  justified. 

5.e.(14)  The  PHASE  OF  WORK  shall  identify  the  timing  of  a  specific  activity 
within  the  entire  project.  If  this  code  is  required  by  project  scheduling  specifications, 
value  for  this  data  will  be  left  justified. 

5.e.(15)  The  CATEGORY  OF  WORK  shall  identify  the  general  type  of  work 
performed  by  every  activity.  If  this  code  is  required  by  project  scheduling 
specifications,  value  for  this  data  will  be  placed  in  the  field. 

5.e.(16)  The  FEATURE  OF  WORK  shall  identify  a  very  broad  designation  of 
the  general  type  of  work  that  is  being  accomplished  by  the  activity.  If  this  code  is 
required  by  project  scheduling  specifications,  value  for  this  data  will  be  left  justified. 
[Usage  note:  Many  systems  require  that  FEATURE  OF  WORK  values  be  placed  in 
several  activity  code  fields.  It  is  recommended  that  users  review  SDEF  documentation 
to  determine  the  correct  way  to  use  a  given  software  system  to  produce  the  FEATURE 
OF  WORK  code.] 

5.f.  Precedence  Record:  The  Precedence  Record(s)  shall  follow  the  Activity 
Records  if  a  Precedence  Diagram  Method  schedule  (PDM)  is  identified  in  the  ARROW 
OR  PRECEDENCE  field  of  the  Project  Record.  The  Precedence  Record  has  the 
following  format: 
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Column  Max. 
Description  Position  Len. 

RECORD  IDENTIFIER  1-4  4 

ACTIVITY  ID  6-15  10 

PRECEDING  ACTIVITY! 7  -  26  10 

PREDECESSOR  TYPE  28-28  1 

LAG  DURATION  30-33  4 


Req. 

Value 

Type 

Notes 

PRED 

Fixed 

Filled 

y 

Integer 

See  Comment  Below 

y 

Integer 

See  Comment  Below 

y 

S,  F,  C 

Filled 

y 

Integer 

Right  Justified 

5.f.(l)  The  RECORD  IDENTIFIER  shall  begin  with  the  four  characters 
“PRED”  in  the  first  four  columns  of  the  record. 


5.f.(2)  The  ACTIVITY  ID  identifies  the  activity  whose  predecessor  shall  be 
specified  in  this  record. 

5.f.(3)  The  PRECEDING  ACTIVITY  number  is  the  number  of  an  activity  that 
precedes  the  activity  noted  in  the  ACTIVITY  ID  field. 

5.f.(4)  The  PREDECESSOR  TYPE  field  indicates  the  type  of  relation  that 
exists  between  the  chosen  pair  of  activities.  Valid  PREDECESSOR  TYPE  fields  are 
as  follows: 

Code  Definition 


S  Start-to-Start  relation 

F  Finish-to-Finish  relation 

C  Finish-to-Start  relation 

[Usage  note:  Some  systems  provide  additional  predecessor  types  that  may  not 
be  supported  by  all  other  systems.  It  is  recommended  that  predecessor  types  be 
restricted  to  the  values  above  regardless  of  the  capabilities  of  the  various  systems 
being  used  for  scheduling.] 

5.f.(5)  The  LAG  DURATION  field  contains  the  number  of  days  delay  between 
the  preceding  and  current  activity.  [Usage  note:  Some  systems  allow  negative  values 
for  the  LAG  DURATION.  Because  these  values  are  not  supported  by  all  other 
systems,  it  is  recommended  that  values  be  restricted  to  zero  and  positive  integers.] 

5,g.  Unit  Cost  Record:  The  Unit  Cost  Record  shall  follow  all  Precedence 
Records.  If  the  schedule  utilizes  the  Arrow  Diagram  Method,  then  the  Unit  Cost 
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Record  shall  follow  any  Activity  records.  There  shall  be  one  Unit  Cost  Record  for  every 
activity  that  is  not  a  lump  sum  activity.  [Usage  note:  (1)  It  is  recommended  that  users 
who  wish  to  exchange  unit  cost  data  contact  SDEF  vendor  representatives  to 
determine  the  ability  of  the  software  system  to  import/export  unit  cost  information.  (2) 
If  the  software  being  used  by  each  member  of  the  project  team  supports  unit  cost  data, 
then  users  may  wish  to  conduct  a  trial  run  of  the  SDEF  data  exchange  with  a  two-  or 
three-activity  network  to  ensure  that  unit  cost  data  transfers  as  expected.  If  problems 
are  found,  please  consult  vendor  representatives  for  resolution  prior  to  exchange  of  full 
project  schedules.  (3)  Unit  cost  record  data  does  not,  in  most  systems,  result  in  the 
correct  values  being  placed  in  the  ACTIVITY  COST  and  COST  TO  DATE  fields  of  the 
Progress  (PROG)  Record.  Users  must,  at  this  time,  manually  transfer  the  data  from 
the  Unit  Cost  Record  to  the  Progress  Record. 

The  fields  for  this  record  shall  take  the  following  format: 


Descriotion 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

UNIT 

Fixed 

Filled 

ACTIVITY  ID 

6-15 

10 

y 

Integer 

See  Comment  Below 

TOTAL  QTY 

17-29 

13 

V 

Format  8.4 

Right  Justified 

COST  PER  UNIT 

31-43 

13 

y 

Format  8.4 

Right  Justified 

QTY  TO  DATE 

45-57 

13 

y 

Format  8.4 

Right  Justified 

UNIT  OF  MEASURE 

59-61 

3 

y 

Alpha. 

Left  Justified 

5.g.(l)  The  RECORD  IDENTIFIER  shall  be  identified  with  the  four  characters 
“UNIT”  placed  in  the  first  four  columns  of  the  record. 

5.g.(2)  The  ACTIVITY  ID  for  each  activity  shall  match  the  format  described 
in  the  activity  record.  Each  activity  may  have  only  one  Unit  Cost  Record. 

5.g.(3)  The  TOTAL  QTY  is  the  total  amount  of  material  to  be  used  in  this 
activity.  This  number  consists  of  eight  digits,  one  decimal  point,  and  four  more  digits. 
An  example  of  a  number  in  this  format  is  “11111111.1111”.  If  decimal  places  are  not 
needed  this  field  shall  still  contain  a  “.0000”  in  columns  25  -  29.  [Usage  note:  Many 
systems  support  a  different  format  for  this  value  that  does  not  include  as  many 
decimal  places.  It  is  recommended  that  users  determine  their  requirements  for 
significant  digits  based  on  the  lowest  common  denominator  of  the  software  systems 
being  used  for  a  given  project.] 
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5.g.(4)  The  COST  PER  UNIT  is  the  cost,  in  dollars  and  cents,  for  each  unit  to 
be  used  in  this  activity.  This  number  consists  of  eight  digits,  one  decimal  point,  and 
four  more  digits.  An  example  of  a  number  in  this  format  is  11111111.1111  .  If 
decimal  places  are  not  needed,  this  field  shall  still  contain  a  “.0000”  in  columns  39  -  43. 
[Usage  note:  Many  systems  support  a  different  format  for  this  value  that  does  not 
include  as  many  decimal  places.  It  is  recommended  that  users  determine  their 
requirements  for  significant  digits  based  on  the  lowest  common  denominator  of  the 
software  systems  being  used  for  a  given  project.] 

5.g.(5)  The  QTY  TO  DATE  is  the  quantity  of  material  installed  in  this  activity 
up  to  the  data  date.  This  number  consists  of  eight  digits,  one  decimal  point,  and  four 
more  digits.  An  example  of  a  number  in  this  format  is  “11111111.1111”.  If  decimal 
places  are  not  needed,  this  field  shall  still  contain  a  “.0000”  in  columns  53-57.  [Usage 
note:  Many  systems  support  a  different  format  for  this  value  that  does  not  include  as 
many  decimal  places.  It  is  recommended  that  users  determine  their  requirements  for 
significant  digits  based  on  the  lowest  common  denominator  of  the  software  systems 
being  used  for  a  given  project.] 

5.g.(6)  The  UNIT  OF  MEASURE  is  an  abbreviation  that  may  be  used  to 
describe  the  units  being  measured  for  this  activity.  Valid  values  for  this  field  are  any 
meaningful  English  or  metric  unit,  except  “LS”  for  Lump  Sum.  Lump  Sum  activities 
are  not  to  have  Unit  Cost  Records. 

5.h.  Progress  Record:  Progress  Record(s)  shall  follow  all  Unit  Cost 
Record(s).  If  there  are  no  Unit  Cost  Record(s),  then  the  Progress  Record(s)  shall  follow 
all  Precedence  Records.  If  the  schedule  utilizes  the  Arrow  Diagram  Method,  then  the 
Progress  Record  shall  follow  any  Activity  Records.  One  Progress  Record  is  required 
for  every  activity  in  the  Activity  Record.  The  fields  for  this  Record  shall  be  provided 
in  the  following  format: 


Descrintion 

Column 

Position 

Max. 

Len. 

RECORD  IDENTIFIER 

1-4 

4 

ACTIVITY  ID 

6-5 

10 

ACTUAL  START  DATE 

17-23 

7 

ACTUAL  FINISH  DATE 

25-31 

7 

REMAINING  DURATION 

33-35 

3 

ACTIVITY  COST 

37-48 

12 

COST  TO  DATE 

50-61 

12 

STORED  MATERIAL 

63-74 

12 

Req. 

Value 

Type 

Notes 

PROG 

Fixed 

Filled 

V 

Integer 

See  Comment  Below 

y 

ddmmmyy 

Filled  if  Started 

y 

ddmmmyy 

Filled  if  Finished 

y 

Integer 

Right  Justified 

y 

Format  9.2 

Right  Justified 

y 

Format  9.2 

Right  Justified 

y 

Format  9.2 

Right  Justified 
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EARLY  START  DATE 
EARLY  FINISH  DATE 
LATE  START  DATE 
LATE  FINISH  DATE 
FLOAT  SIGN 
TOTAL  FLOAT 


76-82  7  V 

84  -  90  7  7 

92  -  98  7  7 

ioo  - 106  7  y 

108  -  108  1  +,  - 

no  - 112  3  y 


ddmmmyy  Filled  if  Not  Started 
ddmmmyy  Filled  if  Not  Finished 
ddmmmyy  Filled  if  Not  Started 
ddmmmyy  Filled  if  Not  Finished 
Fixed  Filled  if  Not  Finished 


Integer  Right  Just,  if  Not 
Finished 


5.h.(l)  The  RECORD  IDENTIFIER  shall  begin  with  the  four  characters 
“PROG”  in  the  first  four  columns  of  the  record. 


5.h.(2)  The  ACTIVITY  ID  for  each  activity  for  which  progress  has  been  posted 
shall  match  the  format  described  in  the  Activity  Record. 

5.h.(3)  An  ACTUAL  START  DATE  is  required  for  all  in-progress  activities. 
The  ACTUAL  START  DATE  shall  be  the  same  as,  or  later  than,  the  PROJECT  START 
date  contained  in  the  Project  Record.  The  ACTUAL  START  DATE  shall  also  be  the 
same  as,  or  prior  to,  the  DATA  DATE  contained  in  the  Project  Record.  If  there  is  an 
ACTUAL  START  DATE  for  an  activity  that  there  must  also  be  a  REMAINING 
DURATION,  and  the  values  for  the  EARLY  START  DATE  and  LATE  START  DATE 
are  blank.  [Usage  note:  Some  systems  allow  default  values  for  ACTUAL  START  DATE 
if  the  date  is  not  entered  by  the  user.  Because  the  failure  to  include  a  start  date  for 
activities  may  result  in  different  schedule  calculations,  it  is  recommended  that  the 
ACTUAL  START  DATE  be  required  for  all  activities  in  progress.] 

5.h.(4)  An  ACTUAL  FINISH  DATE  is  required  for  all  completed  activities.  If 
the  REMAINING  DURATION  of  an  activity  is  zero,  then  there  must  be  an  ACTUAL 
FINISH  DATE.  If  there  is  an  ACTUAL  FINISH  DATE,  then  values  for  the  EARLY 
START  DATE,  LATE  START  DATE,  EARLY  FINISH  DATE,  LATE  FINISH  DATE, 
FLOAT  SIGN,  and  TOTAL  FLOAT  shall  be  blank.  [Usage  note:  Some  systems  allow 
default  values  for  ACTUAL  FINISH  DATE  if  the  date  is  not  entered  by  the  user. 
Because  the  failure  to  include  a  finish  date  for  activities  may  result  in  different 
schedule  calculations,  it  is  recommended  that  the  ACTUAL  FINISH  DATE  be  required 
for  all  activities  in  progress.] 

5.h.(5)  A  REMAINING  DURATION  is  required  for  all  activities.  Activities 
that  have  not  started  shall  have  a  remaining  duration  equal  to  their  original  duration. 
Activities  completed,  based  on  time,  shall  have  a  zero  (0)  REMAINING  DURATION. 
[Usage  note:  Systems  have  a  variety  of  “short-cut”  methods  to  determine  the 
REMAINING  DURATION  value.  It  is  recommended  that  users  actually  consider  the 
time  required  to  complete  the  remaining  work  on  a  given  task,  rather  than  allow  a 
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system  to  calculate  the  remaining  duration  based  on  the  amount  of  work  that  has 
already  been  accomplished.] 

5.h.(6)  The  ACTIVITY  COST  contains  the  estimated  earned  value  of  the  work 
to  be  accomplished  in  the  activity.  An  example  of  a  number  in  this  format  is 
“111111111.11”.  If  decimal  places  are  not  needed,  this  field  shall  still  contain  a  “.00” 
in  the  last  three  columns  of  this  field.  [Usage  note:  Users  should  inquire  of  software 
vendors  if  the  user  needs  to  add  a  zero  in  the  data  field  to  produce  the  default  value 
“0.00”.] 


5.h.(7)  The  COST  TO  DATE  contains  the  earned  value  for  the  activity.  If  there 
is  an  ACTUAL  START  DATE,  then  there  must  also  be  some  value  for  COST  TO  DATE. 
An  example  of  a  number  in  this  format  is  “111111111.11”.  If  decimal  places  are  not 
needed,  this  field  shall  still  contain  a  “.00”  in  the  last  three  columns  of  this  field.  The 
COST  TO  DATE  is  not  tied  to  REMAINING  DURATION.  For  example,  if  the 
REMAINING  DURATION  is  “0”,  the  COST  TO  DATE  may  only  be  95  percent  of  the 
ACTIVITY  COST.  This  difference  may  be  used  to  reflect  5  percent  retainage  for  punch 
list  items.  [Usage  note:  Systems  implement  cost  information  in  different  ways.  It  is 
recommended  that  users  carefully  review  SDEF  documentation  and  test  results  to 
determine  how  to  ensure  that  SDEF  data  is  exported  correctly.] 

5.h.(8)  The  STORED  MATERIAL  field  contains  the  value  of  the  material  that 
the  Contractor  has  paid  for  and  is  on  site  or  in  secure  storage  areas  that  is  a  portion 
of  the  COST  TO  DATE.  An  example  of  a  number  in  this  format  is  “111111111.11”.  If 
decimal  places  are  not  needed,  this  field  shall  still  contain  a  “.00”  in  the  last  three 
columns  of  this  field.  [Usage  note:  Systems  implement  the  stored  materials  field  in 
a  variety  of  ways.  Many  systems  do  not  enforce  STORED  MATERIAL  +  COST  TO 
DATE  <  ACTIVITY  COST.  To  avoid  potential  confusion  between  systems,  it  is 
recommended  that  new  activities  be  added  to  a  schedule  to  reflect  the  cost  of  large 
equipment  procurement  rather  than  use  the  STORED  MATERIALS  field.] 

Recommendations  for  changes  to  these  products  for  enhanced  compatibility 
with  the  SDEF  are  presented  in  each  product's  respective  Appendix  5.h.(9)  The  EARLY 
START  DATE  indicates  the  earliest  date  possible  that  an  activity  can  start  as 
calculated  by  a  CPM  scheduling  system  or  other  Contracting  Officer  approved 
planning  method.  If  the  progress  record  for  an  activity  contains  an  ACTUAL  START 
DATE,  then  this  field  shall  be  blank. 

5.h.(10)  The  EARLY  FINISH  DATE  indicates  the  earliest  date  possible  that 
an  activity  can  finish  as  calculated  by  a  CPM  scheduling  system  or  other  Contracting 
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Officer  approved  planning  method.  If  the  progress  record  for  an  activity  contains  an 
ACTUAL  FINISH  DATE,  then  this  field  shall  be  blank. 

5.h.(ll)  The  LATE  START  DATE  indicates  the  latest  date  that  an  activity  can 
begin  as  calculated  by  a  CPM  scheduling  system  or  other  Contracting  Officer  approved 
planning  method.  If  the  progress  record  for  an  activity  contains  an  ACTUAL  START 
DATE,  then  this  field  shall  be  blank. 

5.h.(12)  The  LATE  FINISH  DATE  indicates  the  latest  date  that  an  activity  can 
finish  as  calculated  by  a  CPM  scheduling  system  or  other  Contracting  Officer  approved 
planning  method.  If  the  progress  record  for  an  activity  contains  an  ACTUAL  FINISH 
DATE,  then  this  field  shall  be  blank. 

5.h.(13)  The  FLOAT  SIGN  indicates  whether  the  float  time  calculated,  using 
a  CPM  scheduling  system  or  other  Contracting  Officer  approved  planning  method,  is 
positive  or  negative  in  nature.  If  the  progress  record  for  an  activity  contains  an 
ACTUAL  FINISH  DATE,  then  this  field  shall  be  blank.  In  the  case  of  zero  float  this 
field  shall  be  blank. 

5.h.(14)  The  TOTAL  FLOAT  indicates  the  total  float  time.  In  the  Precedence 
Diagram  Method  (PDM),  the  total  float  is  the  difference  between  the  early  and  late 
start  or  finish  dates.  In  the  Arrow  Diagram  Method  (ADM),  the  total  float  is  equal  to 
the  late  event  time  at  the  end  of  the  activity,  minus  the  sum  of  the  early  event  time  at 
the  start  of  the  activity  plus  the  duration  of  the  activity. 

5.i.  Project  End  Record:  The  Project  End  Record  shall  be  used  to  identify 
that  the  data  file  is  completed.  If  the  ASCII  End  of  File  character  is  encountered,  then 
data  import  programs  shall  use  that  character  to  infer  that  the  data  continues  on  the 
next  disk.  The  user  shall  then  be  prompted  for  the  next  disk  number,  based  on  the 
VOLM  record  data.  The  Project  End  Record  shall  be  the  last  record  of  the  entire  data 
file,  and  shall  have  the  following  format: 


Description 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-3 

3 

END 

Fixed 

Filled 

5.i.(l)  The  RECORD  IDENTIFIER  for  the  Project  End  Record  shall  be  “END”. 
Data  contained  in  the  data  exchange  file  that  occurs  after  this  record  shall  not  be  used. 
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Appendix  B:  July  1994  Test  Personnel 


Name 


Address 


Telephone/F  ax 


Dave  Balding 

U.S.  Army,  Corps  of  Engineers 
Denver  Resident  Office 

P.0.  Box  1865 

Commerce  City,  CO  80037-1865 

(303)  286-1910 

FAX:  (303)286-1964 

Haskell  Barker 

U.S.  Army  Engineer  District, 

Los  Angeles 

Fort  Irwin  Area  Office 

P.O.  Box  10048 

Fort  Irwin,  CA  92310-0048 

(619)  380-4020 

FAX  (619)  380-2497 

Stan  Green 

Commander,  U.S.  Army  Corps  of 
Engineers 

ATTN:  Mr.  Stan  Green,  CEMP-CE 

20  Massachusetts  Ave.,  N.W. 
Washington,  D.C.  20314-1000 

(202)  272-0206 
FAX:(202)  504-4783 

Steve  Hoyle 

U.S.  Army,  Corps  of  Engineers 

P.O.  Box  4872 

Patrick  AFB,  Florida  32925-7428 

(407)  494-2971 

FAX:  (407)494-2081 

Dennis  Newell 

U.S.  Army,  Corps  of  Engineers 

Florida  Area  Office 

MAILSTOP  COE 

Patrick  AFB,  Florida  32925-7428 

(407)  853-7822 

FAX:  (407)853-3154 

Norm  Sams 

U.S.  Army,  Corps  of  Engineers 
Fairbanks  Resident  Office 

P.O.  Box  35066 

Fort  Wainwright,  AK  99703 

(907)  353-7062 

FAX:  (907)353-7556 
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Glen  Stinn 

U.S.  Army  Engineer  District,  Omaha 

215  N.  17th  Street 

Omaha,  NE  68102-4978 

(402)  221-4166 

FAX:  (402)221-3030 

Dick  Szabo 

U.S.  Army  Engineer  District,  Savannah 
P.O.  Box  889 

Savannah,  GA  31402-0889 

(912)  652-5235 

FAX:  (912)652-5121 

Anita  Thomas 

NASA,  STOP  MS-356 

Langley  Research  Center 

(804)  864-7004 

FAX:  (804)864-7890 
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Appendix  C:  July  1994  Questionnaire 

1.  Is  the  SDEF  specifically  noted  in  the  Table  of  Contents  ?  Yes  /  No 

2.  If  there  is  no  specific  section  on  the  SDEF  is  there  a  general  discussion  of  data 
import  and  export  routines  that  includes  the  SDEF  ?  Yes  /  No 

3.  Is  the  SDEF  specifically  noted  in  the  Index  ?  Yes  /  No  /  No  Index 

4.  In  what  Section  or  Chapter  does  the  SDEF  material  appear: 

5.  On  what  page(s)  does  the  SDEF  material  appear: 

6.  Is  there  separate  discussion  of  SDEF  import  ?  Yes  /  No 

6a.  Does  the  system  support  SDEF  import  ?  Yes  /  No  (  page  #:  ) 

6b.  Are  there  specific  discussions  about  what  data  fields  are  supported  for  SDEF 
import  and  what  fields  are  not  supported  ?  Yes  /  No  (  page  #:  ) 

6c.  If  there  are  specific  discussions  about  what  data  fields  are  supported  for  SDEF 
import,  please  circle  any  of  the  following  items  that  are  noted  in  the 
documentation  and  provide  page  numbers. 

(1)  Arrow  or  Precedence  Notation  ?  Yes  /  No  /  Not  Described  (  page  #.  ) 

(2)  Project  Start  and  End  Dates  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(3)  Multiple  Calendars  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(4)  Holiday  Dates  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(5)  Activity  Milestones  or  Constraints?  Yes  /  No  /  Not  Described  ( page  #:  ) 

(6)  Hammock  Activities  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(7)  Workers  Per  Day  Code  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(8)  Responsibility  Code  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(9)  Work  Area  Code  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(10)  Mod  or  Claim  Number  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(11)  Bid  Item?  Yes /No /Not  Described  (page#:  ) 
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(12)  Phase  of  Work  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(13)  Category  of  Work  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(14)  Feature  of  Work  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(15)  Types  of  Lags  in  Precedence  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(16)  Unit  Cost  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(17)  Budgeted  Earned  Value  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(18)  Remaining  Duration?  Yes  /  No  /  Not  Described 

( page  #: 

) 

(19)  Cost  to  Date  ?  Yes  /  No  /  Not  Described 

( page  #: 

) 

6d.  If  the  system  supports  SDEF  import,  do  the  manuals  explain  procedures  to  set 
the  system's  default  values  for  the  SDEF  import  ?  Yes  /  No  (  page  #:  ) 

6e.  If  the  system  supports  SDEF  import,  does  the  system  automatically  set  up  the 
SDEF  default  values  for  the  SDEF  import  ?  Yes  /  No  (  page  #:  ) 


7.  Is  there  separate  discussion  of  SDEF  export  ?  Yes  /  No 


7a.  Does  the  system  support  SDEF  export  ?  Yes  /  No  (  page  #:  ) 

7b.  Are  there  specific  discussions  about  what  data  fields  are  supported  for  SDEF 
export  and  what  fields  are  not  supported  ?  Yes  /  No  (  page  #:  ) 

7c.  If  there  are  specific  discussions  about  what  data  fields  are  supported  for  SDEF 
export,  please  circle  any  of  the  following  items  that  are  noted  in  the  documenta¬ 
tion  and  provide  page  numbers. 


(1)  Arrow  or  Precedence  Notation  ?  Yes  /  No  /  Not  Described  (  page  #: 

(2)  Project  Start  and  End  Dates  ?  Yes  /  No  /  Not  Described  (  page  #: 

(3)  Multiple  Calendars  ?  Yes  /  No  /  Not  Described  (  page  #: 

(4)  Holiday  Dates  ?  Yes  /  No  /  Not  Described  (  page  #: 

(5)  Activity  Milestones  or  Constraints  ?  Yes  /  No  /  Not  Described  (page  #: 

(6)  Hammock  Activities  ?  Yes  /  No  /  Not  Described  (  page  #: 

(7)  Workers  Per  Day  Code  ?  Yes  /  No  /  Not  Described  (  page  #: 

(8)  Responsibility  Code  ?  Yes  /  No  /  Not  Described  (  page  #: 

(9)  Work  Area  Code  ?  Yes  /  No  /  Not  Described  (  page  #: 

(10)  Mod  or  Claim  Number  ?  Yes  /  No  /  Not  Described  (  page  #: 

(11)  Bid  Item  ?  Yes  /  No  /  Not  Described  (  page  #: 

(12)  Phase  of  Work  ?  Yes  /  No  /  Not  Described  (  page  #: 

(13)  Category  of  Work  ?  Yes  /  No  /  Not  Described  (  page  #: 

(14)  Feature  of  Work  ?  Yes  /  No  /  Not  Described  (  page  #: 

(15)  Types  of  Lags  in  Precedence  ?  Yes  /  No  /  Not  Described  (  page  #: 

(16)  Unit  Cost  ?  Yes  /  No  /  Not  Described  (  page  #: 


) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 

) 
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(17)  Budgeted  Earned  Value?  Yes /No /Not  Described  (page#:  ) 

(18)  Remaining  Duration  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

(19)  Cost  to  Date  ?  Yes  /  No  /  Not  Described  (  page  #:  ) 

7d.  If  the  system  supports  SDEF  export,  do  the  manuals  explain  procedures  to  set 
the  system's  default  values  for  the  SDEF  export  ?  Yes  /  No  (page  #:  ) 

7e.  If  the  system  supports  SDEF  export,  does  the  system  automatically  set  up  the 
SDEF  default  values  for  the  SDEF  export  ?  Yes  /  No  (page  #:  ) 
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Appendix  D:  AlderGraf,  Version  5.2 


The  custom  version  of  the  system  tested,  which  included  additional  files  and 
instructions,  met  the  SDEF  specifications  for  creating  SDEF  files  and  is  recommended 
for  use  by  Contractors  and  Corps  of  Engineers  offices  for  this  use.  Use  of  the  system 
to  import  SDEF-compatible  files  is  not  recommended  at  this  time  due  to  errors  found 
while  importing  actual  cost  data.  Before  using  the  AlderGraf  system  to  export  SDEF 
files,  users  should  review  the  additional  information  found  in  this  report. 

The  SDEF  point  of  contact  is  Mr.  Leon  C.  Alderfer,  AlderGraf  Systems,  Inc.,  10620 
Stebbins  Circle,  Suite  B,  Houston,  TX  77043;  Telephone  (713)  467-8500,  FAX  (713) 
467-1062. 


Installing  the  Software 


•  Did  the  program  tested  appear  to  be  a  distribution  version  of  the  software  ?  Yes 
Version  5.2  is  the  distribution  version  of  the  system. 

•  Did  the  program  require  additional  files  not  contained  on  the  system  disks  ?  Yes 

Additional  program  disks  were  required.  The  vendor  indicated  that  the  recommended 
changes  noted  in  this  test  report  would  be  (1)  available  on  a  supplemental  program 
disk  to  Version  5.2  and  (2)  incorporated  into  the  next  production  version,  Version  5.3, 
to  be  released  1  May  1995. 

Creating  an  SDEF-Compatible  Project 


SDEF  import  and  export  routines  are  built  into  the  program  structure  and  are  very 
easy  to  find  and  use.  The  routines  provide  prompts  and  quickly  create  the  necessary 
files  on  a  data  disk  (in  the  case  of  the  export  routine)  or  the  new  project  (in  the  case  of 
importing  an  SDEF  file). 
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It  is  recommended  that  the  SDEF  documentation  be  included  in  the  AlderGraf  users 
manual.  In  addition,  template  projects  should  be  provided  with  future  versions  of 
AlderGraf  so  that  users  do  not  have  to  modify  data  structures  to  meet  SDEF 
requirements. 

Once  the  software  was  installed,  a  sample  project  was  created  following  the  supple¬ 
mental  SDEF  directions.  The  sample  project  was  entered  manually  into  the  software 
system.  SDEF  output  files  generated  through  AlderGraf  will  be  made  available 
through  anonymous  ftp  service  through  “ftp.cecer.army.mil”.  The  files  will  be  con¬ 
tained  in  the  subdirectory  “asce/sdef/files”. 

•  Was  SDEF  documentation  provided  with  the  system  ?  Yes 

Two  text  files  that  needed  to  be  printed  were  contained  on  the  supplemental  data  disk. 

•  Was  SDEF  documentation  sufficient  for  easy  creation  of  SDEF  projects  ?  Yes 

Supplemental  SDEF  documentation  describes  the  process  of  creating  files  compatible 
with  the  SDEF  format.  This  additional  documentation  explains  how  users  must  define 
the  code  structures  that  need  to  be  changed  in  AlderGraf  for  the  system  to  meet  the 
SDEF  requirements.  Once  the  user  creates  a  template  project,  the  custom  project 
may  be  used  to  create  future  SDEF  projects  without  the  need  to  customize  AlderGraf 
data  structures.  While  this  process  should  be  familiar  to  AlderGraf  users,  care  must 
be  exercised  to  follow  the  supplemental  instructions  exactly. 

The  following  tables  show  how  data  should  be  formatted  for  each  record.  Comments 
guide  the  user  in  matching  the  product's  data  to  the  SDEF,  and  indicate  any 
difficulties  encountered  or  recommendations.  In  the  Req.  Value  column,  a  check  mark 
means  that  the  data  is  required.  For  a  dash  (-)  in  the  Req.  Value  column  or  “See  spec 
in  the  Notes  column,  check  the  explanation  for  that  item  in  the  draft  SDEF  specifi¬ 
cation  (Appendix  A). 


Table  D1 .  AlderGraf  Volume  Record  data  format. 


Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 

RECORD 

IDENTIFIER 

1  -4 

4 

VOLM 

Fixed 

Filled 

•  Is  VOLM  record  on  line  one 
(1)  of  the  SDEF  file  produced 
for  this  system?  Yes 

DISK  NUMBER 

6-7 

2 

✓ 

Number 

Right  Justified 

Table  D2.  AlderGraf  Project  Record  data. 


constraints  and  various  project  end  dates.  Because  the  “End  Date  Current”  field  may 
affect  schedule  calculations,  users  should  leave  this  field  blank.  It  Is  recommended 
that  revised  SDEF  documentation  discuss  the  limitations  on  use  of  a  PROJECT 
END  date  to  constrain  the  CPM  calculations. 


Table  D3.  AlderGraf  Calendar  Record  data  format. 


Table  D4.  AlderGraf  Holiday  Record  data  format. 


Table  D5.  AlderGraf  Activity  Record  data  format. 
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AlderGraf  allows  only  a  single  type  of  unit  cost  data  to  be  used  on  a  given  project.  Users  with  more  than  one  type  of  unit  cost  will  need  to  manually  modify  the  SDEF 
file  following  export  to  ensure  that  the  UNIT  OF  MEASURE  values  are  correctly  identified  for  each  unit  cost  record. 

For  activities  using  unit  costs,  the  unit  cost  and  progress  cost  information  should  be  automatically  calculated.  The:  “Budgeted  Cost”  field  should  be  set  equal  to  the 
COST  PER  UNIT  times  the  TOTAL  QTY.  The  STORED  MATERIAL  equal  zero.  COST  TO  DATE  should  be  set  equal  to  QTY  TO  DATE  times  COST  PER  UNIT. 
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Table  D9.  AlderGraf  Project  End  Record  data  format. 


Column 

Max. 

SDEF  Field 

Position 

Len. 

Value 

Notes 

Comments 

RECORD  IDENTIFIER 

1  -3 

3 

END 

Fixed 

None 

Exporting  an  SDEF  File 

The  export  routines  are  built  directly  into  the  AlderGraf  menu  structure  and  are  very 
easy  to  find  and  use. 

Although  the  export  process  erases  the  target  diskette  prior  to  export,  a  list  of  files  on 
the  disk  is  shown  and  the  user  is  given  the  opportunity  to  put  in  another  disk  prior  to 
proceeding.  This  is  a  very  good  feature  of  the  export  routine. 

The  extension  “.txt”  on  text  files  is  common  to  the  point  of  becoming  almost  standard 
for  ASCII  files.  In  addition,  the  “edit”  and  “notepad”  systems  assume  “.txt”  extensions. 

It  is  recommended  that  the  production  version  of  the  SDEF  routines  provide 
the  default  extension  of  “.txt”  for  all  export  files. 

Features  that  go  beyond  those  of  the  SDEF  are  not  checked  during  the  export  process. 
The  result  is  that  SDEF  files  may  he  created  that  do  not  include  all  necessary 
information  for  consistent  scheduling  calculations.  An  example  is  the  use  of  Start-to- 
Finish  sequence.  It  is  recommended  that  the  production  version  of  the  SDEF 
routines  report  errors  on  all  items  that  may  cause  deviation  between  the 
capabilities  of  the  AlderGraf  system  and  the  capacity  of  the  SDEF  to  accept 
those  capabilities. 


Importing  an  SDEF  File 

The  most  significant  finding  during  the  import  process  was  that  actual  cost  data  was 
not  imported  correctly.  Because  importing  actual  cost  data  is  critical  to  the  effective 
use  of  the  SDEF,  additional  import  checks  were  not  performed.  THE  SYSTEM  MUST 
BE  REVISED  PRIOR  TO  ANY  FURTHER  IMPORT  TESTING  OR  POSSIBLE 
FUTURE  RECOMMENDATION  FOR  USE  OF  THE  SYSTEM  FOR  IMPORTING 
SDEF  FILES. 
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Conclusions 

Once  a  template  project  is  created  and  used  for  SDEF  projects,  the  AlderGraf  system 
quickly  produces  a  correctly  formatted  SDEF  file.  User  requirements  for  entering 
what  could  be  considered  “trivial”  cost  data  should  be  eliminated  in  the  next  release 
of  the  system.  Programs  for  importing  SDEF  files  must  be  revised  prior  to  recom¬ 
mendation  of  this  system  for  importing  SDEF  files. 
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Test  Project  Description 

The  project  used  to  test  the  system  was  the  “Warehouse  Project”  used  as  an  example 
throughout  the  Associated  General  Contractors  of  America's  publication  Construction 
Planning  and  Scheduling  (Associated  General  Contractors  of  America,  **date).  Pages 
47  and  243  of  this  publication  contain  some  of  the  figures  for  this  project.  The 
sequence  between  the  activities  was  developed  using  start-to-start  and  finish-to-finish 
logic  from  the  bar  chart  on  page  243.  Progress  values  were  obtained  for  the  project 
from  page  242. 
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Appendix  E:  Open  Plan,  Version  5.1 


Distribution  version  5.1,  when  supplemented  with  a  disk  that  included  additional 
program,  project,  and  template  files,  met  the  SDEF  specifications  and  is  recommended 
for  use  by  Contractors  and  Corps  of  Engineers  offices  for  SDEF  export  and  import. 
Before  using  the  AlderGraf  system  to  import  or  export  SDEF  files,  users  should  review 
the  additional  information  found  in  this  report. 

The  SDEF  points  of  contact  at  Welcom  Software  Technology  are  Chris  Jensen  and 
Randy  Armstrong,  WST  Corporation,  15995  North  Barkers  Landing,  Suite  275, 
Houston,  TX  77079;  telephone  (713)  558-0514,  FAX  (713)  584-7828. 

Installing  the  Software 

•  Did  the  program  tested  appear  to  be  a  distribution  version  of  the  software  ?  Yes 

•  Did  the  program  require  additional  files  not  contained  on  the  system  disks  ?  Yes 

A  data  disk  received  on  12  January  1995  was  required  in  addition  to  existing  program 
files. 

When  installing  the  sample  projects,  an  error  occurred  after  responding  “Yes”  to  the 
question  regarding  overwriting  the  project  directory.  The  error  message  was  a  “Syntax 
Error.”  The  offending  line  of  code  that  was  displayed  was  “&q”.  After  selecting  the 
“ignore”  option,  the  remainder  of  the  program  files  loaded  correctly.  Also,  after 
working  with  the  system  for  some  time  the  tester  deleted  the  projects  and  templates 
and  re-installed  them  without  a  problem.  This  was  unexpected,  because  the  initial 
installation  had  resulted  in  errors. 

It  is  recommended  that  the  installation  problem  be  corrected  prior  to 
including  the  SDEF  routines  as  part  of  Open  Plan  distribution  disks.  It  is  not 
known  if  selecting  the  “ignore”  option  has  caused  additional  problems  with 
the  imported  programs.  This  item  will  not  keep  the  system  from  being 
recommended  for  SDEF  export/import. 
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Creating  an  SDEF-Compatible  Project 

The  software  was  installed  and  instructions  in  the  supplemental  documentation  were 
followed  to  modify  the  data  structure  and  add  the  supplemental  program,  templates, 
projects,  and  reports.  The  sample  project  PDMC  was  copied  to  a  new  project  and  a  test 
project  was  entered  manually.  An  update  of  the  sample  project  was  also  created  with 
simulated  progress.  Copies  of  these  sample  projects  were  saved  using  the  software 
system's  backup  utility  for  future  reference.  A  copy  of  the  backup  files  will  be  provided 
to  software  vendors  upon  request.  Files  will  be  made  available  to  all  others  via  anony¬ 
mous  ftp  service  through  cecer.army.mil. 

•  Was  SDEF  documentation  provided  with  the  system?  Yes 

SDEF  documentation  was  provided  in  a  separate  three-ring  binder.  The  instructions 
provided  were  excellent  and  covered  all  aspects  of  installing  the  supplemental  pro¬ 
grams,  templates  and  projects.  Of  all  the  vendors  supplemental  documentation  re¬ 
ceived,  the  Open  Plan  documentation  was  the  best.  It  is  recommended  that  the  SDEF 
documentation  be  included  in  a  future  distribution  version  of  the  documentation. 

•  Was  SDEF  documentation  sufficient  for  easy  creation  of  SDEF  projects?  Yes 

The  following  tables  show  how  data  should  be  formatted  for  each  record.  Comments 
guide  the  user  in  matching  the  product's  data  to  the  SDEF,  and  indicate  any  diffi¬ 
culties  encountered  or  recommendations. 

In  the  Req.  Value  column,  a  check  mark  means  that  the  data  is  required.  For  a  dash 
(-)  in  the  Req.  Value  column  or  “See  spec”  in  the  Notes  column,  check  the  explanation 
for  that  item  in  the  draft  SDEF  specification  (Appendix  A). 


Table  El.  Open  Plan  Volume  Record  data  format. 


Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 

RECORD  IDENTIFIER 

1  -4 

4 

VOLM 

Fixed 

Filled 

Is  VOLM  record  on  line  one  (1)  of 
the  SDEF  file  produced  for  this 
system?  No 

DISK  NUMBER 

6-7 

2 

y 

Number 

Right  Justified 

None 
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Table  E4.  Open  Plan  Holiday  Record  data. 


SDEF  Field 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

HOLI 

Fixed 

Filled 

CALENDAR  CODE 

6-6 

1 

✓ 

Alpha. 

Filled 

HOLIDAY  DATE 

8-14 

7 

✓ 

ddmmmyy 

Filled 

HOLIDAY  DATE 

16-22 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

24-30 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

32-38 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

40-46 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

48-54 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

56-62 

7 

! 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

64-70 

7 

!  ~ 

i  “ 

f  •  - . - . 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

|  72-78 

7 

L: . - . 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

80-86 

7 

t 

j - - - 

ddmmmyy 

:  May  be  Filled 

HOLIDAY  DATE 

88  -94 

7 

I  - 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

96-102 

7 

- 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

104-110 

7 

- 

ddmmmyy 

May  be  Filled 

■j- . -  .  ■  - 

HOLIDAY  DATE 

112-118 

7 

j  - 

ddmmmyy 

May  be  Filled 

HOLIDAY  DATE 

120-126 

7 

J _ 

ddmmmyy 

!  May  be  Filled 

General  Comments:  Calendars  that  are  not  used  by  any  activities  are  included  in  the 
export  file.  It  is  recommended  that  only  the  calendars  in  use  be  exported.  Changing  the 
export  routines  to  only  export  the  calendars  used  will  not  keep  the  program  from  being 
recommended  for  SDEF  import/export  use. 
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Table  E9.  Open  Plan  Project  End  Record  data  format. 


Column 

Max. 

Req. 

SDEF  Field 

Position 

Len. 

Value 

Type 

Notes 

Comments 

RECORD  IDENTIFIER 

1  "3 

3 

END 

Fixed 

Filled 

None 

Exporting  an  SDEF  File 

The  export/import  routines  are  included  as  menu  items  under  the  Utilities 
menu.  It  is  recommended  that  references  to  the  Corps  of  Engineers  be 
removed  from  the  menu  selection.  All  references  to  the  format  should  only 
be  called  the  “Standard  Data  Exchange  Format,”  which  should  increase 
awareness  and  use  of  the  format. 

The  export  routine  appears  to  work  according  to  the  SDEF  specification, 
provided  the  items  noted  in  Creating  an  SDEF-Compatible  Project  above 
are  considered  when  creating  a  project  and  editing  activities. 


Importing  an  SDEF  File 

As  noted  in  supplemental  SDEF  documentation,  users  should  begin  the 
import  process  by  copying  a  template  project,  either  ACOE  or  PCOE,  over  to 
a  new  project  name.  ACOE  or  PCOE  should  be  used  because  they  do  not 
contain  any  activities.  If  the  user  selects  a  project  that  contains  activities, 
then  he  or  she  will  need  to  delete  all  activities  in  the  project.  Importing  data 
into  an  existing  project  will  overwrite  those  activities  with  matching  Activity 
IDs.  Activities  that  are  in  the  file  prior  to  the  import  that  are  not  overwritten 
will  remain  in  the  project.  It  is  recommended  that  a  clarification  of  this 
point  be  included  in  revised  SDEF  documentation. 

The  import  routine  does  not  automatically  recalculate  the  schedule.  It  is 
recommended  that  users  recalculate  the  schedule  after  importing  the  data. 


Conclusions 

Use  of  Open  Plan  template  projects  allows  users  to  quickly  develop  and 
export  projects  that  meet  the  SDEF. 
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Differences  between  scheduling  systems  within  Open  Plan  depend  largely  on 
the  version  of  the  database  engine  that  is  behind  Open  Plan.  Dbase  IV  was 
used  during  testing,  with  mixed  results.  Before  using  the  import  routines  for 
“real”  data,  users  may  want  to  use  the  routines  on  a  small  test  file  to  ensure 
that  data  is  correctly  imported  into  the  system. 


Acknowledgments 
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Corporation,  for  numerous  discussions  with  Corps  representatives  over  the 
course  of  the  testing  to  resolve  various  issues. 


Test  Project  Description 

The  project  used  to  test  the  SDEF  routines  in  Open  Plan  was  a  four-unit 
housing  construction  project.  The  table  below  shows  the  activity  list  that  was 
used  as  the  basis  for  the  project.  Activity  Codes  and  costs  were  added  to  this 
schedule  for  use  in  SDEF  testing. 


Table  E10.  Open  Plan  test  project  activity  list. 


No. 

Activity  Name 

Days 

Priors 

1 

Deliver  Materials 

5 

- 

2 

Excavate 

2 

1 

3 

Drainage 

2 

2 

4 

Landscape 

4 

3 

5 

Make  Roof 

4 

1 

6 

Make  Walls 

6 

1 

7 

Foundation 

5 

2 

8 

Structure 

5 

5,  6,7 

9 

Doors  &  Windows 

3 

8 

10 

Electrical 

3 

8 

11 

Mechanical 

4 

8 

12 

Plumbing 

2 

8 

13 

Fence 

3 

4 

14 

Appliances 

2 

9,10,11,12 

15 

Interior  Finish 

3 

9,10,11,12 

16 

Hot  Tub 

2 

9,  10, 11, 12, 13 

17 

Clean-Up 

2 

14,  15, 16 
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Appendix  F:  PMS-80,  Version  6.40 

The  custom  version  of  the  system  tested  (including  additional  files  and 
instructions),  met  the  SDEF  specifications,  and  is  recommended  for  use  by 
Contractors  and  Corps  of  Engineers  offices.  At  the  time  of  this  report,  all 
needed  programming  changes  have  been  made  and  included  in  a  supple¬ 
mental  program  disk.  Until  the  production  version  of  the  system  containing 
the  SDEF  programs  is  complete,  PMS-80  customers  may  obtain  copies  of  the 
SDEF  routines  directly  from  Pinnel-Busch  Engineers.  The  SDEF  programs 
are  to  be  incorporated  into  version  6.40  to  be  released  in  April  1995. 
Additional  information  found  in  this  report  may  be  used  as  a  supplement  to 
system  documentation  and  should  be  reviewed  prior  to  using  the  system  for 
SDEF  import/export. 

The  SDEF  point  of  contact  for  PMS-80  is  Perry  Smith,  Pinnell-Busch,  Inc., 
6420  S.W.  Macadam  Avenue,  Suite  330,  Portland,  OR  97201;  tel:  (503)  293- 
6280. 


Installing  the  Software 

•  Did  the  program  tested  appear  to  be  a  distribution  version  of  the 
software?  No 

Test  files  received  January  9,  1995  for  version  6.40  were  updated  to  solve 
several  items  discussed  below.  Additional  program  files  were  received 
February  9, 1995. 

•  Did  the  program  require  additional  files  not  contained  on  the  system 
disks?  Yes 


Creating  an  SDEF-Compatible  Project 


Once  the  software  was  installed,  the  sample  project  was  entered  manually 
into  the  software  system.  A  copy  of  the  backup  files  will  be  provided  to 
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software  vendors  upon  request.  Files  will  be  made  available  to  all  others  via 
anonymous  ftp  service  through  cecer.army.mil. 

•  Was  SDEF  documentation  provided  with  the  system?  Yes 

Additional  pages  were  provided  that  describe,  with  figures,  the  procedure  to 
be  followed  when  using  the  SDEF.  Instructions  were  provided  for  creating 
projects  and  activities  compatible  with  the  SDEF  format.  The  instructions 
also  contain  the  information  needed  to  ensure  that  PMS-80  users  will  be  able 
to  create  SDEF  schedules  without  any  problems. 

•  Was  SDEF  documentation  sufficient  for  easy  creation  of  SDEF  projects? 

Yes 

Users  familiar  with  the  PMS-80  system  should  have  no  problem  following  the 
instructions  provided.  Users  familiar  with  the  Split/Merge  facility  to  create 
project  schedules  should  note  that  all  activity  codes  except  the  Feature  of 
Work  code  are  copied  to  new  activities  during  the  merging  process.  It  is 
recommended  that  the  “Feature  of  Work”  code  be  included  as  part  of  the 
Split/Merge  process.  This  item  will  not  keep  the  system  from  being 
recommended  for  SDEF  import/export. 

The  following  tables  show  how  data  should  be  formatted  for  each  record. 
Comments  guide  the  user  in  matching  the  product  s  data  to  the  SDEF,  and 
indicate  any  difficulties  encountered  or  recommendations.  In  the  Req.  Value 
column,  a  check  mark  means  that  the  data  is  required.  For  a  dash  (-)  in  the 
Req.  Value  column  or  “See  spec”  in  the  Notes  column,  check  the  explanation  for 
that  item  in  the  draft  SDEF  specification  (Appendix  A). 


Table  FI .  PMS-80  Volume  Record  data  format. 


SDEF  Field 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

Comments 

RECORD  IDENTIFIER 

1  -4 

4 

VOLM 

Fixed 

Filled 

•  Is  VOLM  record  on  line  one  of 
the  SDEF  file  produced  for  this 

system?  Yes 

DISK  NUMBER 

6-7 

2 

y 

Number 

Right 

Justified 

None 

Table  F2.  PMS-80  Project  Record  data  format. _ 

Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 
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Table  F9.  PMS-80  Project  End  Record  data  format. 

Column  Max.  Reqd. 

SDEF  Field  Position  Len.  Value  Notes  Comments 

RECORD  IDENTIFIER  1  -  3 _  3  END  Fixed  None. 

Exporting  an  SDEF  File 

The  PMS-80  export  routine  is  designed  and  executed  well  and  consistently  with  other 
PMS-80  screens.  Users  familiar  with  PMS-80  will  have  no  trouble  exporting  data  files. 

It  is  recommended  that  previous  version  of  PMS-80  be  removed  from  the 
menu,  because  there  is  only  one  version  of  the  format. 

To  assist  users,  a  DOS  “disk  not  found”  and  other  similar  hardware-related  error 
messages  should  be  trapped,  allowing  users  not  to  have  to  deal  with  the  “Abort,  Retry, 
Fail?”  prompt. 

Importing  an  SDEF  File 

Problems  found  during  import  and  creation  of  a  new  file  have  been  corrected  in  the 
February  1995  program  update. 

After  import,  users  must  recalculate  the  schedule. 

Conclusions 

PMS-80  provides  an  integrated  approach  to  developing,  importing,  and  exporting 
SDEF  files.  The  areas  to  coordinate  with  others  when  using  PMS-80  are  the  use  of 
multiple  calendars,  length  of  the  ACTIVITY  IDs,  and  the  RESPONSIBILITY  CODE 
data.  Coordination  is  needed  in  these  areas  because  PMS-80  limits  the  values  more 
closely  that  does  the  SDEF. 
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Test  Project  Description 

The  following  project  was  used  as  the  basis  for  the  project  schedule  used  to  test  PMS- 
80.  Activities  3-11  were  copied  using  the  “Split/Merge”  feature  of  PMS-80  to  develop 
a  complete  schedule.  Following  the  initial  test  of  export  data,  specific  activities  were 
modified  on  an  ad-hoc  basis  to  test  multiple  calendars,  variations  in  cost,  hammock 
activities,  and  other  items. 


No.  Description 

Dur 

Prior 

Resp 

Wkr/ 

day  Area 

Bid 

Ph. 

Cat 

Feature 

$ 

1  I  Notice  to  Proceed 

1 

none 

. . . _ . . . 

0 

2  Procure  Matl  and 

,  Equip 

90 

1 

0 

3  Survey  Road 

2 

2 

SUR 

3  ONE 

1 

1 

1 

Surveying 

2,000 

4  Clear  and  Grub 

2 

3 

LBR 

10  ONE 

1 

1 

1 

To  Grade 

10,000 

5  Cut  and  Fill 

4 

4 

DOZ 

5  ONE 

1 

1 

1 

To  Grade 

5,000 

6  Rough  Grade 

6 

5,10 

DOZ 

5  ONE 

1 

1 

1 

To  Grade 

20,000 

7  Place  Gravel 

2 

6 

TRK 

3  ONE 

1 

1 1 

2 

Final  Grade 

15,000 

8  Compact  Roadbed 

4 

7 

ROL 

5  ONE 

1 

1 

2 

Final  Grade 

10,000 

9  Excavate  for  Culvert 

3 

4 

HOE 

5  ONE 

2 

1 

3 

Culverts 

20,000 

10  Place  Culvert 

1 

9 

HOE 

5  ONE 

2 

1 

3 

Culverts 

3,000 

11  Prepare  Inlet  and 

Outlet 

5 

10 

DOZ 

3  ONE 

2 

1 

3 

Culverts 

15,000 
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Appendix  G:  PPMS-30,000,  Version  4.02 


A  production  version  of  the  system  was  tested.  This  custom  version  met  the  SDEF 
specifications  and  is  recommended  for  use  by  contractors  and  Corps  of  Engineers 
offices  for  the  creation  and  exchange  of  SDEF-compatible  arrow  diagram  files. 
Additional  information  found  in  this  report  must  be  reviewed  prior  to  successfully 
using  the  system  for  import/export  of  SDEF  files. 

The  SDEF  point  of  contact  was  Justin  Smith,  Advanced  Project  Approach,  Inc.,  P.O. 
Box  802070,  Dallas,  TX  75380;  telephone  (214)  929-1877,  FAX  (214)  929-1490. 

Installing  the  Software 

•  Did  the  program  tested  appear  to  be  a  distribution  version  of  the  software?  Yes 

•  Did  the  program  require  additional  files  not  contained  on  the  system  disks?  No 


Creating  an  SDEF-Compatible  Project 

Once  the  PPMS-30,000  software  was  installed,  the  sample  project  was  entered 
manually  into  the  software  system.  A  copy  of  the  backup  files  will  be  provided  to 
software  vendors  upon  request.  Files  will  be  made  available  to  all  others  via  anony¬ 
mous  ftp  service  through  cecer.army.mil. 

•  Was  SDEF  documentation  provided  with  the  system?  Yes 

Section  15  of  the  User's  Manual  contains  a  brief  description  of  file  transfer  operations, 
including  the  SDEF  files;  however,  the  necessary  level  of  detail  for  these  instructions 
has  not  been  provided.  It  is  recommended  that  supplemental  user  documenta¬ 
tion  be  developed  to  assist  users  in  creating  SDEF-compatible  files. 

Appendix  20  lists  the  SDEF  but  does  not  contain  the  most  recent  version  of  it.  It  is 

recommended  that  the  correct  specification  be  used. 
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The  SDEF  Point  of  Contact,  listed  above,  provided  additional  information  during 
telephone  calls.  The  information  obtained  is  provided  in  the  appropriate  sections  of 
this  test  report.  It  is  recommended  that  revised  SDEF  documentation  contain 
the  complete  set  of  information  needed  to  correctly  use  the  SDEF. 

•  Was  SDEF  documentation  sufficient  for  easy  creation  of  SDEF  projects?  No 

Detailed  test  results  provide  the  additional  information  required  during  this  test  to 
create  a  correct  SDEF  file.  It  is  recommended  that  the  additional  information  required 
during  the  test  be  included,  in  some  fashion,  in  revised  SDEF  documentation. 

The  following  tables  show  how  data  should  be  formatted  for  each  record.  Comments 
guide  the  user  in  matching  the  product's  data  to  the  SDEF,  and  indicate  any 
difficulties  encountered  or  recommendations.  In  the  Req.  Value  column,  a  check  mark 
means  that  the  data  is  required.  For  a  dash  (-)  in  the  Req.  Value  column  or  “See  spec” 
in  the  Notes  column,  check  the  explanation  for  that  item  in  the  draft  SDEF 
specification  (Appendix  A). 


Table  G1.  PPMS  Volume  Record  data  format. 


Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 

RECORD  IDENTIFIER 

1-4 

4 

VOLM 

Fixed 

Filled 

Is  VOLM  record  on  line  one 
(1)  of  the  SDEF  file 
produced  for  this  system? 

Yes 

DISK  NUMBER 

6-7 

2 

«/ 

Integer 

Right  Justified 

None. 

1 - - - - - 

Table  G2.  PPMS  Project  Record  data  format. _ 

Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 


USACERL  TR-95/40 


91 


■o  co  "o  £ 

<D  -C  £  ±3 

i  «  _c 

O  <D  a)  ±i  .2 

1  g  <5  5  £  u. 

“  -O  *=  r-  UJ 

®  "2  §- J  o  Q 
^  E  c  <0 
8  -g  8  |  o  -o 

g«#;§s 

P  c  3  XI  d  > 

ai?Sg8 

»1  £  ^  |  t? 

S  8  £  CO  ••§  ■§ 

5  CD  c  2  "o  3 
CO  3  3  g-  "g  O 

^  w.  Q_  TO  c 
<0  Q)  Om-'O” 

rr4-  o  ©  « 

«  w  -  jo  c  “ 

£  2  ©  $  >>.£ 

3  £  to  3  5  O 

©tTJC^0" 

*-  E?  C  ®  E  •> 
(flog  =2r 
5“  8 

9-  «  £  S' « 

■“  (O  H  £  TJ 

0)  _  >  *♦-  a> 

^3  ®  g  I 

8h^3E  . 

co  .  E  S  2  g  5 

s-  CO  05  CO  3  8  .9 

°  u  o  ^  n)  L  (5 

c  o  c  o  o  «  S 

.9.  O  tn  £  “  S 


O  O  CO  m 

c  ,®  c  o  o  «  5 

-B  2  «  £  -  Z  § 

«  <d  ®  <8  “  E 

3  =  —  12  CD  4_J  a 

ort->ocg 

rt  )r  S  2  £  o  o 

O  .2  *E  a  a  aTJ 


|>s 

§  8-8-g 

1  8  2? 

|  c  o.  ® 

®.o-  E 

os  «  E 
octg 

xi  ®  se  ® 

|  1=5  ®  g 

c  o  ■=  ■—  O 

>,  o  2  .t-  ’5 

co  ^  a>  2 
c  „  V- 

c  a)  a>  jr  5 

S  8  ?  S  1 

z  ®  -I  E  g 

f.c? 

O®  «  |g 

ils|8 

°?  co  <0  ®  T> 

2  i  =  E  f 

£  2  £  "  5 

"l.i’lc 
iH  Sil 

y)  fl)  >  T3 

2  So  *  5 
g-tgo 
gtO=C 

c  &•  £  jj 

^  .b  ®  O 

gu.  g  |c 
o  UJ  W  -  O 
Cl  O  m  CL 

co  S  g  w 

c  g  £  £ 


'  T>  E 
BBc 

m 

«  5  3 

~  o 
o  y  -o 

2  1  H 

Q.  >  Q 

y,  W  <0 

I  In 
=  *-  » 
«LU  1 

s 

CL  <  _ 

□-  Z  .E 


co  -Q  if)  c 

5-  §  •  “ 

®  "<5  ®  ® 
•”  o  £  E 
Hl"  o  3 
W  P  “  o 

Q  «  ®  5 

(/3  ®  E  ° 

L  I  CL  o  II 

DC  «  *§  Q 
gw 

■l2gl 

8)0  ®  £ 

co  o  —  .E 

°z  il 

-D  O  2  o 
oO  «  .E 


CD  2 

|®S 

850 

.£  ®  c 
«  2  « 

§ouj 

8  so 

If? 

4-  c  _ 

||® 

^  «  a 

d)-o  .£ 

|«n 

Ip 

2  g  CL 
^  §  CD 

B  §  -Q 

Q  ^  = 

g  -o'  5 

<  8.-S 
■e  eq 
°  ®  > 
t  - 1 
8.1  p 

§•  ®  O 

«-§< 
CO  -Q  LL 
2  ®  UJ 
Q.  -g  Q 
Q-  W  CO 


ddmmmyy 

Alpha. 

> 

GC 

111 

LL 

H 

Z 

UJ 

in 

q 

h- 

< 

Q 

o 

LU 

< 

H 

o 

< 

DC 

Q 

0- 

Table  G3.  PPMS  Calendar  Record  data  format. 


Table  G5.  PPMS  Activity  Record  data  format.  _ 

Column  Max.  Req. 

Description  Position  Len.  Value  Type  Notes  Comments 

RECORD  1-4  4  ACTV  Fixed  Filled  None. 

IDENTIFIER 
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Table  G6.  PPMS  Precedence  Record  data  format. 


SDEF  Field 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

PRED 

Fixed 

n/a 

ACTIVITY  ID 

6-15 

10 

y 

Integer 

n/a 

PRECEDING  ACTIVITY 

17-26 

10 

y 

Integer 

n/a 

PREDECESSOR  TYPE 

28-28 

J _ _ j 

y 

S,  F,  C 

n/a 

LAG  DURATION 

30-33 

4 

y 

Integer 

n/a 

Comment:  Precedence  projects  are  not  supported  by  PPMS. 

Table  G7.  PPMS  Unit  Cost  Record  data  format. 


SDEF  Field 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

RECORD  IDENTIFIER 

1-4 

4 

UNIT 

Fixed 

n/a 

ACTIVITY  ID 

6-15 

10 

7 

Integer 

n/a 

TOTAL  QTY 

17-29 

13 

7 

Format  8.4 

n/a 

COST  PER  UNIT 

31  -  43 

13 

7 

Format  8.4 

n/a 

QTY  TO  DATE 

45-57 

13 

y 

Format  8.4 

n/a 

UNIT  OF  MEASURE 

59-61 

3 

y 

Alpha. 

n/a 

Comment:  Unit  Cost  data  is  not  supported  by  PPMS. 

Table  G8.  PPMS  Progress  Record  data  format. 

Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 
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Table  G9.  PPMS  Project  End  Record  data  format. 


SDEF  Field 

Column  Max.  Req. 

Position  Len.  Value  Notes  Comments 

RECORD  IDENTIFIER 

1-3 

3  END 

Fixed 

None. 

Exporting  an  SDEF  File 

The  SDEF  export  routine  is  built  into  the  program  structure  and  is  very  easy  to  find 
and  use.  The  routine  prompts  users  for  needed  information  and  quickly  creates  the 
SDEF  data  file.  More  than  one  SDEF  export  file  may  be  created  on  a  floppy  disk. 

In  the  Req.  Value  column,  a  check  mark  means  that  the  data  is  required.  For  a  dash 
(-)  in  the  Req.  Value  column  or  “See  spec”  in  the  Notes  column,  check  the  explanation 
for  that  item  in  the  draft  SDEF  specification  (Appendix  A).  PPMS  has  menu  selections 
for  SDEF  1990  and  SDEF  1993.  The  SDEF  1990  format  is  no  longer  a  valid  format. 

It  is  recommended,  that  the  SDEF  1990  selection  be  deleted  from  the 
distribution  version  of  PPMS. 

Users  will  need  to  review  material  in  this  Appendix  to  ensure  that  a  correctly 
formatted  SDEF  file  is  created.  It  is  recommended  that  revised  SDEF  docu¬ 
mentation  include  instructions  needed  to  develop  a  schedule  in  PPMS  that 
will  output  in  a  correctly  formatted  SDEF  file. 


Importing  an  SDEF  File 

Importing  routines  trap  unsupported  data  to  provide  users  with  information  about 
what  has  been  ignored  during  file  import.  A  list  of  items  that  are  required  for  correctly 
importing  to  PPMS,  as  noted  in  the  test  report  above,  should  be  provided  to  other 
project  stakeholders.  Organizations  developing  schedules  for  import  into  PPMS  should 
be  notified,  through  revision  to  local  specifications,  or  in  writing  to  ensure  that  items 
not  supported  by  PPMS  are  not  included  in  the  SDEF  file. 

PPMS  has  menu  selections  for  SDEF  1990  and  SDEF  1993.  The  SDEF  1990  format  is 
no  longer  a  valid  format.  It  is  recommended  that  the  SDEF  1990  selection  be 
deleted  from  the  distribution  version  of  PPMS. 

The  import  routine  may  not  set  the  activity  type  of  the  first  activity  to  the  proper 
activity  type,  as  noted  under  the  Outstanding  Export  Routine  Issues,  item  number  two 
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listed  above.  Users  will  have  to  make  this  change  following  the  import  process.  It  is 

recommended  that  revised  SDEF  documentation  cover  this  point. 

Existing  project  numbers  cannot  be  overwritten  during  the  SDEF  import  routine.  This 
is  a  useful  safety  feature  of  the  import  routine  and  is  documented  on  page  15-4  of  the 
PPMS  user  documentation. 

Following  the  import  of  an  SDEF  file,  the  schedule  must  be  recalculated.  This  is 
documented  on  page  15-9. 

It  is  recommended  that  the  name  of  the  export  file  have  an  extension  of  “.txt”.  The  text 
file  extension  is  fairly  common  to  the  point  of  becoming  almost  standard  for  ASCII 
files.  In  addition,  the  “edit”  and  “notepad”  systems  assume  “.txt”  extensions.  It  is 

recommended  that  the  production  version  of  the  SDEF  routines  provide  the 
default  extension  of  “.txt”  for  all  export  files. 


Conclusions 

PPMS  version  4.02  is  recommended  for  use  by  Corps  and  Contractor  offices  for  use  in 
developing  SDEF  files.  If  the  system  is  to  be  used  for  importing  data  developed  from 
other  systems,  the  following  items  should  be  addressed,  either  by  specification  or  by 
separate  letter:  (1)  arrow  diagrams  only,  (2)  no  unit  cost  data  in  the  schedule,  (3)  no 
stored  material  costs  will  be  paid  only  through  a  separate  activity,  (4)  only  one 
calendar  is  to  be  used  in  the  schedule,  (5)  the  MOD/CLAIM  NUMBER,  PHASE  OF 
WORK  and  FEATURE  OF  WORK  codes  need  not  be  used  and  (6)  BID  ITEM  and 
CATEGORY  OF  WORK  codes  default  to  “1”  for  all  activities 
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Test  Project  Description 

The  project  used  to  test  the  system  was  the  small  office  project  used  in  the  Corps  of 
Engineers,  the  PROSPECT  Training  course  entitled  Network  Analysis  Systems. 
Figure  27-A  contains  the  arrow  diagram  for  the  test  project.  Costs  were  added  to  the 
network  to  simulate  sample  project  data.  Following  creation  of  the  initial  schedule, 
updates  were  made  to  the  project  and  an  update  created. 
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Appendix  H:  Primavera,  Version  5.1  (DOS) 


With  additional  files  and  instructions,  the  production  version  of  the  system  tested  met 
the  SDEF  specifications  and  is  recommended  for  use  by  Contractors  and  Corps  of 
Engineers  offices.  At  the  time  of  this  report,  several  additional  programming  changes, 
noted  below,  are  being  completed.  Revised  user  documentation  is  also  being  produced. 
A  complete  set  of  supplemental  materials  will  be  available  in  April  1995.  To  obtain  a 
copy  of  the  SDEF  routines  users  should  contact  one  of  the  SDEF  Points  of  Contact 
noted  below.  Until  the  revised  documentation  is  completed,  users  are  encouraged  to 
review  this  report  for  supplemental  data  not  found  in  vendor  documentation. 

Persons  considering  the  purchase  of  related  products  from  Primavera  Systems  should 
note  that  only  the  DOS  version  of  Primavera  have  SDEF  routines. 

The  SDEF  point  of  contact  is  Marko  Vranich,  Technical  Support  Representative,  or 
Hank  Norris,  Software  Tester,  Primavera  Systems  Inc.,  Two  Bala  Plaza,  Bala  Cynwyd, 
PA  19004;  telephone  (610)  667-8600,  FAX  (610)  667-7894. 

Installing  the  Software 

•  Did  the  program  tested  appear  to  be  a  distribution  version  of  the  software?  Yes 
Version  5.1  is  a  distribution  version  of  the  program. 

•  Did  the  program  require  additional  files  not  contained  on  the  system  disks?  Yes 
An  additional  program  disk  was  required. 


Creating  an  SDEF-Compatible  Project 


Once  the  software  was  installed,  the  sample  project  provided  with  the  supplemental 
data  disk  was  copied,  using  P3  routines,  to  a  new  project  BLD0.  The  test  project  was 
entered  into  the  BLD0  project  and  the  schedule  calculated.  An  update,  BLD1,  was  also 
created.  Both  of  these  projects  were  saved  onto  floppy  disks  using  the  Primavera 
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backup  utility.  A  copy  of  the  backup  files  will  be  provided  to  software  vendors  upon 
request.  SDEF  export  files  will  be  provided  as  part  of  the  SDEF  Checker  program. 

•  Was  SDEF  documentation  provided  with  the  system?  Yes 
Documentation  was  provided  as  separate  pre-printed  pages. 

•  Was  SDEF  documentation  sufficient  for  easy  creation  of  SDEF  projects?  Yes 

It  is  recommended  that  users  copy  the  SDEF  sample  project  to  the  new  project  name 
because  all  activity  codes  and  custom  data  items  required  are  in  the  SDEF  standard 
project. 

Users  must  install  the  supplemental  SDEF  routines  in  the  correct  directories. 
The  installation  software  does  not  make  this  obvious.  Carefully  reading  and 
following  the  installation  instructions  contained  in  the  supplemental  user 
documentation  is  mandatory  for  successful  use  of  the  SDEF  routines. 

The  following  tables  show  how  data  should  be  formatted  for  each  record.  Comments 
guide  the  user  in  matching  the  product's  data  to  the  SDEF ,  and  indicate  any  diffi¬ 
culties  encountered  or  recommendations. 

In  the  Req.  Value  column,  a  check  mark  means  that  the  data  is  required.  For  a  dash 
(-)  in  the  Req.  Value  column  or  “See  spec”  in  the  Notes  column,  check  the  explanation 
for  that  item  in  the  draft  SDEF  specification  (Appendix  A). 


Table  HI .  Primavera  Volume  Record  data  format. 


SDEF  Field 

Column 

Position 

Max. 

Len. 

Req. 

Value 

Type 

Notes 

Comments 

RECORD 

IDENTIFIER 

1  -4 

j 

4 

VOLM 

Fixed 

_ _ _ _ _ j 

Filled 

•  Is  VOLM  record  on  line  one  (1)  of 
the  SDEF  file  produced  for  this 
system?  Yes 

DISK  NUMBER 

6-7 

2 

✓ 

Number 

Right  Justified 

None. 

Table  H2.  Primavera  Project  Record  data  format. 

Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 


USACERL  TR-95/40 


105 


oO| 
w  CE  « 

.CD 

®  Z  ® 
0.0  w 
.S-o  | 

®  2  c 

o£8 

a---  o. 


«  "2  c 

'  m  ° 

5x2 

♦-  (D 

®  §r 

_Q  C  n> 

.  E<$.g 

3  U  T3 
C  C  © 
4-  o  © 
Cfl 

2  0)  ^ 
cF2 
80S 
©  £  o 


Q  JC  — 
CO  0  o 

o  *5  -O 
_r-  </3  nx 


O 

hi  S,  cc 
£  «  iu 

^=“ 
a>  ■=  £ 
to  S  3 

E  ~  o 

■  ®  3  < 

g,  00c 

»  r  z 

BOO 
|  8-0 

Ec£ 

a  ®-o 
•  •  c 
©  —  ^ 
X  U-  © 

zgf 

'  d  W  S 

1  ®  ®  .2 

©  JC  <0 

kl  4-*  1_ 

1  O  H-  O 

:  co  o  > 


§ 

s  03 

©  .E  -c 
£  3  x> 

o  O  g 

3  CO  w 

co  ^  © 
■oai5 

.E  £  j= 

Li=  3  W 
L  C  © 

*  o  a>  5 
^  o  °  -E 

i  B  cf 
!  8  I  o 

J  3  O  © 

1  h  C/3  *; 

;  5  c  fi 

-  £  o  *- 

[  T>  «  © 

’■g  ®  - 

-  ®  OT  -a 

;  |  e5 

:  o  £  E 

■  £  a  ^ 

!  .52  a>  = 

;  -  £  E 

=  r£  -C  M 

!  ®  S’  5 

!fp 

:  03  ®  ■§ 

:  =i  13  -g 
i  3  3 

I  -D  r  ■= 

■  ®  §  s 

)  o  w  03 
J  CO  4-4  c 

)  ^  o  C 
)  ^  CD  ^ 

-  a)  'o'  to 

-  >  SI  >» 

-  ©  CL  CO 


start  no  earlier  than  milestone  with  a  date  of  the  contract  start  date.  There  should  n 
be  any  information  placed  in  the  “Contract  Start  Date”  field.  It  is  recommended 
that  revised  SDEF  documentation  provide  this  information. 
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Table  H3.  Primavera  Calendar  Record  data  format. 


Column  Max.  Req. 

SDEF  Field  Position  Len.  Value  Type  Notes  Comments 

RECORD  IDENTIFIER 

1  -4 

■ 

CLDR 

Fixed 

Filled 

None. 

CALENDAR  CODE 

6-6 

i 

y 

Alpha. 

See  Spec 

Primavera  can  accept  alpha¬ 
numeric  designations  for  calen¬ 
dar  codes,  but  some  systems 
do  not  accept  these.  It  is 

recommended  that  revised 

SDEF  documentation  instruct 

users  to  create  calendars 
with  only  numeric  calendar 
codes. 

WORKDAYS 

8-14 

m 

SMTWTFS 

Fixed 

Filled 

None. 

CALENDAR  DESCRIPTION 

16-45 

30 

y 

Alpha. 

Left  Justified 

None. 

Table  H5.  Primavera  Activity  Record  data  format. 

Column  Max.  Req. 

SOEF  Field  Position  Len.  Value  Type  Notes  Comments 


WORKERS  PER  DAY  67  -69  3  -  Integer  Right  Justified  This  code  is  supported  in  the  SDEF  sample  project.  It  is  recommended 

that  users  copy  the  sample  project  to  the  new  project  name  rather  than 
modifv  activity  codes  to  support  the  SDEF. 
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Q 

GO 


< 

LU 

LL 


Primavera  allows  the  creation  of  specialized  types  of  activities  called  “milestones”  and  “flags”.  Until  the  release  of  supplemental  vendor  documentation  and  follow-up 
instructions  from  Primavera  software  tester,  Mr.  Norris,  it  is  recommended  that  these  specialized  activity  types  not  be  used  for  SDEF  projects.  Dates  may  be  fixed 
on  specific  activities  through  use  of  the  CONSTRAINT  DATE  and  CONSTRAINT  TYPE  field. 


Table  H6.  Primavera  Precedence  Record  data  format. 
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Table  H9.  Primavera  Project  End  Record  data  format. 


Column 

Max. 

Req. 

SDEF  Field 

Position 

Len. 

Value 

Type 

Notes 

Comments 

RECORD  IDENTIFIER 

1  -3 

3 

END 

1 

Fixed 

Filled 

' - 

None. 

Exporting  an  SDEF  File 

SDEF  export/import  routines  are  provided  under  a  separate  set  of  executable  and 
batch  files.  Single-user  versions  of  Primavera  require  that  the  user  exit  Primavera 
prior  to  invoking  the  export  routines. 

As  noted  in  the  user  documentation,  the  SDEF  export/import  program  must  be  located 
in  the  correct  directory  for  the  program  to  operate  correctly.  If  the  “p3sdef”  program 
terminates  unexpectedly,  please  review  the  installation  instructions  for  the  proper 
location  of  the  programs. 

The  system  uses  “resources”  to  allocate  cost  and  unit  costs  to  each  activity.  First-time 
users  of  the  SDEF  export  routine  who  have  not  followed  the  instructions  above 
regarding  cost  items  and  unit  costs,  will  very  likely  produce  incorrect  SDEF  export 
files.  Care  must  be  taken  to  enter  data  as  discussed  in  the  previous  discussion  so  that 
the  export  routine  creates  a  correct  SDEF  file. 

The  export  routine  assumes  that  the  file  is  to  be  saved  on  the  same  drive  and  path  as 
the  P3  program  files.  This  is  an  awkward  arrangement  for  those  who  use  the  system 
but  are  not  computer  literate.  Users  are  forced  to  do  selective  directory  listings  to  find 
the  files  that  were  produced.  It  is  recommended  that  the  production  version  of 
the  SDEF  export  routine  be  modified  to  allow  users  to  specify  the  location  of 
the  export  file.  The  Primavera  software  tester,  Mr.  Norris,  indicates  that 
exporting  to  floppies  will  not  be  included  in  the  SDEF  export  routines  at  this 
time. 


The  file  name  produced  does  not  have  a  “.txt”  extension.  As  a  result,  users  may  have 
to  rename  the  files  produced  prior  to  creating  the  data  disk.  It  is  recommended  that 
the  production  version  of  the  SDEF  export  routine  be  modified  to  include  the 
“.txt”  extension  as  part  of  every  file  name.  Primavera  software  tester,  Mr. 
Norris,  indicates  that  export  routines  will  add  the  “txt”  extension  if  none  has 
been  provided. 
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Importing  an  SDEF  File 

SDEF  export/import  routines  are  provided  under  a  separate  set  of  executable  and 
batch  files.  Single-user  versions  of  Primavera  require  that  the  user  exit  Primavera 
prior  to  invoking  the  export  routines. 

The  import  file  fails  when  importing  an  project  with  a  name  that  is  already  in  the  P3 
project  listing. 

Unit  cost  data  was  imported  with  the  following  results: 

1.  The  TOTAL  QUANTITY  field  was  truncated  from  the  SDEF  requirement  of  8.4  to 
the  P3-allowable  value  of  5.2.  For  example,  the  number  an  SDEF  file  of 
“12345678.1234”  was  imported  as  “45678.12”. 

2.  The  COST  PER  UNIT  field  was  truncated  from  the  SDEF  requirement  of  8.4  to  the 
P3-allowable  value  of  5.2.  For  example,  the  number  in  the  SDEF  file  of 
“98765432.1234”  was  imported  as  “32.00”. 

3.  The  first  COST  PER  UNIT  value  encountered  in  the  SDEF  file  was  imported,  as 
noted  above.  This  value  appeared  in  the  resource  dictionary  under  the  appropriate 
location.  IMPORTING  MORE  THAN  ONE  UNIT  COST  ITEM  IN  A  FILE  WILL 
RESULT  IN  INCORRECT  IMPORT  OF  THE  UNIT  COST  DATA.  Primavera 
may  have  a  fix  for  this  item  by  the  time  of  publication  of  this  report.  It  is 
recommended  that  any  users  interested  in  unit  costs  contact  P3  technical 
support  to  determine  the  current  status  of  the  unit  cost  routines. 


Conclusions 


Due  to  the  complexity  of  resource  information  available  in  the  system,  it  is  likely  that 
casual  users  will  have  difficulty  creating  correctly  formatted  SDEF  cost  information. 
User  documentation  should  be  improved  to  provide  more  specific  instructions.  Users 
who  need  Unit  Cost  data  should  contact  P3  support. 

The  requirement  that  users  copy  files  may  be  too  much  for  casual  computer  users. 
SDEF  programs  should  be  modified  to  support  different  disk  drives  and  file  names. 
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Test  Project  Description 

The  project  used  to  test  the  SDEF  export  was  a  four-story  building  based  on  the 
activity  list  shown  in  the  table  below.  An  alphanumeric  identification  scheme  was 
used  in  this  schedule.  For  example,  the  first  floor  Structural  Steel  and  Pan  Forms 
activity  has  an  activity  identification  of  “101A”,  the  second  floor  “101B’  and  so  on, 
through  the  fourth  floor.  Activities  were  added  for  the  Submittal,  Approval  and 
Delivery  phases. 


Table  H10.  Primavera  test  project. 


Number 

Description 

Duration 

Priors 

1 

Structural  Steel  and  Pan  Forms 

5 

2 

Place  Floor  Slab 

16 

1 

3 

Steel  Studs  for  Partition  Walls 

8 

2 

4 

Wall  Insulation 

5 

10 

5 

Mechanical  Rough-In 

7 

10 

6 

Electrical  Rough-In 

7 

10 

7 

Install  Finish  Drywall 

7 

4,  5,6 

8 

Doors  and  Hardware 

8 

7 

9 

Painting 

5 

8 

10 

Exterior  Siding 

8 

3 

11 

Appliances  and  Furnace 

~~  6 

9 

12 

Floor  and  Trim 

3 

11 

13 

Bathroom  and  Kitchen  Cabinets 

3 

13 

14 

Finish  Plumbing 

5 

11,  13 

15 

Finish  Electrical 

5 

11, 13 

16 

Install  Furnjshings 

2 

14,15 
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